We are using Lerna to manage multiple packages, but those packages are owned by different teams. And for example, team A doesn't need to know or care about team's B packages.
Is there a way to configure Lerna in local machine to show and hide packages ?
Or what is the common practices the community are doing in this scenario ?
Related
My team is developing a React component library which relies on MaterialUI components. The customer of our employer wants to automatically signal and/or upgrade outdated dependencies (specifically when the dependency on MaterialUI becomes outdated at least). We are using yarn as dependency manager.
I found yarn lists all the outdated dependencies (or a specific dependency if specified) through the yarn outdated command. One can then upgrade said dependencies using the yarn upgrade command to which the dependency to be updated is supplied as parameter. To do this using a single command, running yarn upgrade-interactive lists outdated dependencies which the user can then select to be updated.
I am wondering if there is/are way(s) to automate this process. I tried piping the results of yarn outdated to yarn update as well as yarn version, but yarn upgrade seems to ignore whatever input it receives and updates every package regardless and yarn version throws errors saying the version are not proper semvers.
I realise yarn upgrade-interactive makes this process easy and quick for developers, however the project is intended to become open-source over time and the customer prefers a centralised solution rather than relying on every individual contributor to track this themselves. As far as I am aware, yarn upgrade-interactive cannot be automated as it requires user input in order to select the package(s) to be updated.
Other solutions I found, such as Dependabot or packages like 'yarn-outdated-notifier', seem to only work with GitHub. The project is currently running on Azure DevOps and, when it goes public, will run on GitLab.
Is there any way we could do this in our CI/CD environment or with any (free) solutions? The customer prefers to have as few dependencies as possible.
I'm trying to setup a mono repo and came across lerna+yarn. My problem is, what is the actual advantage I get in using lerna. I can use yarn workspaces only and have the same functionality. I came across the following Are there any advantages to using Lerna with Yarn workspaces? but here there is no specific answer as to the specific advantage of using lerna.
as stated in the yarn workspaces documentation,
workspaces are the primitives that tools like lerna can use
You might have a project that only needs workspaces as "primitives", and not lerna. Both are tools, but lerna as a higher-level-tool than yarn workspaces helps you organize your monorepo when you are working on open source or in a team:
The install (bootstrap) / build / start-scripts are at the project root:
meaning one install and package resolution instead of one for each package
node_modules at the root is 'fat', in sub-projects it's tiny: One place to look for when you resolve package conflicts
parallel execution of scripts in sub-projects: E.g. starting up both server and frontend development in watch-mode can just be one command
publishing and versioning is much easier
There is certainly a lot of overlap between the two. The big difference is that Lerna handles package management, versioning and deployment.
We have a distributed system with many services which talk to each other.
Sometimes a code change in one service will require a feature to have been deployed in another service.
We use octopus to deploy all the things which is cool but we really want to prevent services from being deployed before the things they depend on are deployed.
Is there a way we can do this with octopus deploy?
For example can I make the nuget package for one service depend on an explicit version range of another package?
If you don't want to deploy all your projects as one massive deployment with a series of steps that push your different services to different machines, then I don't think there's a built-in way to make your deployments dependent on each other's version numbers like that. (see this uservoice suggestion in Octopus asking for that very feature)
However, I do think that you could write a powershell script that ran as a pre-deployment step and checked the version number of one nuget package against a version range stored in another. Then the ps script could halt or allow deployment accordingly.
I've yet to find suitable advice on a sustainable continuous deployment workflow that fits our organizations applications. We're currently using a single, large repository to house all our source code, with multiple VS2010 *.sln files to group related products/tools. We're also using a branch strategy similar to the develop and master outlined in this great article though via mercurial not git. The applications vary widely from public websites, internal websites, windows services, utilities, and development tools.
Even some of the comprehensive examples I found don't really address deployment at various levels within the repository (unless I missed it).
My default build points at the main.sln at the root of the repository -- building all projects in the respository. This configuration is also set to build any feature branches.
The feature branches are branches of the entire repository, but I don't want to deploy everything to test, just the contents of that sub-solution. I aslo don't want to require branches be merged to develop prior to being built. How do I indicate to TeamCity (or my repository) that I only want to deploy specific projects, which could vary between feature branches?
Note: This is similar to this SO question, but with emphasis on multiple smaller projects that have different usages/release requirements.
I have 3 projects in my solution that I want to deploy. Is there a nice and quick way of using Visual Studio's setup projects to deploy all three apps using one MSI and letting the user decide which apps he wants to install during the install process?
I have setup projects for the 3 individual apps, I also have an overarching setup project that has the output of those other three projects. Am I on the right track or is there a better way?
I think you probably want merge modules. Accrding to MSDN:
A merge module is a standard feature of Microsoft Windows Installer that packages components together with any related files, resources, registry entries, and setup logic. You can use merge modules to install components that multiple applications share. You cannot install merge modules directly. You must merge them into deployment projects.
http://support.microsoft.com/kb/827025
In your case, each application would be a merge module and you would need to provide some UI to select which applications you would like to install. You could modify one of the default page templates to do that.
If using WiX (which I suggest doing) then you break each project down into its components, each project would be represented as a Feature in WiX/MSI which you can do conditional installs on. The standard tree dialog on installers for selecting features is based on this and the WiX examples have a ready made UI that uses it.
As for merge modules the lead developer of WiX was involved in the early creation of the Merge Module specs and he reccomends using .wixlibs now. See Here
WiX v3 Docs
I also have a similar requirement, however i used merge modules but cant seem to find a way of selecting which specific msm to install and which not to. As i understand there is a no condition property which can be set on msm's while integrating them with msi's. Please let me know if there is some alternate way of doin so..
Thanks,
Apn
You can use Wix as i've posted here -->
VS 2005 Setup Projects: Deploy Many Projects With One MSI