I would like to know how to manage dependencies updates between branches.
Example:
Working on branch A with a module in v3
Updating the module via npm on branch B
Working on branch A again
Since modules in node_modules are the same between branches, the module is still in v4 when back on branch A.
This generates an error because a function doesn't exist in v4 anymore.
Is there a way to manage this without having to re-install the correct version each time we switch branches ?
Related
Has anyone experienced how to add an existing NodeJS API to an existing (Angular) Nx Monrepo?
Unfortunately the manual doesn´t help me so much
https://nx.dev/migration/manual
The process of migrating a repo into your mono repo requires a few manual steps. I think there would not be a simpler way to do it.
Assuming your node project does not share files with your current monorepo, this should be the steps:
on your node repo, create a branch 'to-monorepo' and in it, move all the files to folders that match the nx folder structure and push the commits to it.
remove your package.json file (we will later merge it with the monorepo's one)
once the folders match the nx folder structure, time to merge into the monorepo. From the monorepo add the remote of the other repo
git remote add node-repo <your git repo's node url>
at the monorepo folder, checkout your master
run a pull to make the node repo branches be available in the monorepo
git pull
create a new branch 'merging-node-repo' on your monorepo.
merge the branch node-repo/to-monorepo into your merging-node-repo branch, preserving the history:
git merge node-repo/to-monorepo --allow-unrelated-histories
push your new branch (all the code and its history will now be listed in this new branch)
remove the remote node-repo from your local monorepo configs
git remote rm node-repo
manually merge all the node repo's original package.json file dependencies into the monorepo's one, and run npm install from the monorepo. This way your package-lock.json file is updated. Once you are done, create a commit and push it.
this last step is more tricky. You have now to manually update the monorepo's config files to allow nx to start managing it. This is where the link you had in your question might help. Once you are done, create a commit and push it.
With these steps you can then merge your merging-node-repo branch into master.
I recommend you to create a separated nx workspace with a nodejs project on it. This helps you with having a baseline for all the necessary nx configurations and dependencies.
You might want to make sure your project works via nx commands from this separated workspace; this way you will have a better chance of getting configurations of your monorepo right.
Hopefully this gets you started.
Here is a solution that I wrote and used to import multiple repos into a single monorepo, under whatever subdirectories are wanted, while maintaining commit history:
https://github.com/marcuswestin/monorepo-merge
I've also found two other scripts that look like they might work, but I haven't tried them:
http://choly.ca/post/git-merge-to-monorepo/
https://github.com/ksindi/monoreaper
Consider that there are two npm projects, package-a and package-b, which are hosted in a private gitlab instance. package-a depends on package-b via git+ssh protocol.
Now as an engineer I need to modify some code in package-b. Before I merge my change to the trunk branch, I hope that I can test my change with package-a to avoid unexpected bugs. How can I let package-a use the package-b that contain the un-merged changes?
Gitlab provides a corresponding refs/merge-requests/$iid/merge for the merge result of the merge, which could be used for this purpose.
Let's say, your merge request id in project-b is 106, then you can run the following command in the project-a to test with your merge request
npm install 'git+ssh://git#git.yourcompany.com:products/package-b.git#merge-requests/106/merge'
More reading: https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47110
I am following standard gitflow, and I have different environments for testing the dev builds, and release builds. master goes to production.
I also have my JS app divided into multiple private npm modules which goes into private npm repository.
Q1
Is there any way I can version my npm packages, against the branches they are built on in a standard way?
What I have tried is, I have prerelease pre-ids added to the versions. like
1.0.0-rc.0 //for master
1.0.0-beta.0 //for release
1.0.0-alpha.0 //for dev
But if I create a feature branch from master, it contains the master's version. When I try to raise a PR from it to dev, then it shows conflict, since dev has -alpha.x in its version. To resolve the conflict, I'll have to consume the target branch's versioning. Same issue when it goes for merging on release branch too.
And when it comes to merging to master, the release version (one with -beta.0) completely replaces the master.
So it becomes like this: on master,
| It was | After Merge | After version bump |
| ------------- |:-------------:| -------------------:|
| 1.0.0-rc.0 | 1.0.0-beta.0 | 1.0.0-rc.0 |
Ideally after the version bump i would have wanted it to be 1.0.0-rc.1
Is it possible to keep package JSONs out of versioning.
Q2
How do I control the versioning in the package JSON of the application where these NPM modules are consumed? It too is on gitflow and feature branching model, and I would want that the App, when it is building on dev branch, it builds with artifacts that are published from their respective dev branches.
Honestly, I might be misusing gitflow too, but as of now, too confused to figure out where I'm going wrong.
Any Help will be appreciated.
Thanks in Advance
The way I solved it is,
//${buildNumber} and ${branch} are available as env variables in the build agent(at least available in jenkins/bamboo)
tagversion="1.0.0-${branch}.${buildNumber}"
echo $tagversion
npm version $tagversion
so my builds are created and published as
1.0.0-master.1 //for master
1.0.0-release.1 //for release
1.0.0-dev.1 //for dev
You can user merge strategy as ours for package.json file in all branches. Details steps as below:
Configure merge.ours.driver as true
git config --global merge.ours.driver true
Add .gitattributes file on each branch
Add .gitattributes file with below content on each branch as below:
echo 'package.json merge=ours' >> .gitattributes
More details, you can refer last part (Merge Strategies) in Git Attributes.
Until now, for most situations, package.json file won't be overwritten during merge.
Note: pakage.json file will be overwritten for recursive merge. When merging changes from branch1 to branch2, if the file package.json is only changed on branch1, the merge commit will keep the package.json file with the version from branch1 by recursive merge strategy.
Such as on master branch, the version 1.0.0-rc.0 has not changed; while on release branch, the version has changes to 1.0.0-beta.0. When merging changes from release branch into master branch, the version will be 1.0.0-beta.0 (as you mentioned).
So for recursive merge situation, you need to manually change the package.json file version after merging:
# On the merged branch, as master in above example
git checkout head~ -- package.json
git commit -m 'use the original package.json after recursive merge'
I've done few searches before posting but none of them helped me.
I hold a git repository for my personal website, and I have a small problem when checking out one of its branches. There are 3 branches for different tools or frameworks : the former master branch, which acts as the current version of my website, & the Elm and Vue ones, that I'm working on at the same time. Each of these branches contains a package.jsons file and so a node_modules directory. My problem is : after checking out a branch, I have to 'yarn install' my packages to run the dev mode or build the app (with webpack), because of all the conflicted packages hosted in the same directory on different versions I guess.
It's a bit tiring to reinstall the required packages each time I checkout a branch. Moreover, I have then to commit the updated yarn.lock file.
So I am wondering if there is a way to create a specific node_modules folder or sub-folder, one for each branch, in order to have "scoped" directories. Or should I better separate this repo in 3 repos ?
I hope I am clear about this problem.
Thanks for reading !
You can commit node_modules so git will switch them on git checkout.
Or you can create separate worktrees. Checkout different branches in different worktrees and don't switch branches afterwards.
I am developing a very complex app that is using internally developed, open source NPM modules.
I often need to change one of those modules (extra features, bug fixing, etc.) in order for the main application to work.
At the moment, I have:
A directory called my_modules, each containing a git repository one for each module. For example module1, module2.
A directory called my_apps, where for example there is app1 which has module1 as a dependency
Under my_apps/app1/node_modules I have module1 and module2, installed via NPM
In the server, deploy by pulling the git repository, running an npm install and npm dedupe, and running the server with forever.
At this stage, if I have to fix something in one of the modules, I:
Fix it within my_apps/app1/node_modules/module1 (not git)
When it's all working, COPY the files over to my_modules/module1 and do a git push and npm publish
The server will pull the latest modules after deploy thanks to npm install
This is way, way less than ideal. It's just too error-prone. However:
Having a symbolic link link my_apps/app1/node_modules/module1 => my_modules/module1 means that module1 will look for dependencies in its own path, which often causes problems (for example, I need to make sure that EVERY module uses the same copy of module1, which is imperative)
Having a git repo under my_apps/app1/node_modules/module1 feels dangerous, in case I accidentally overwrite changes using NPM on the module. Also, once fixed the change in the local git repo, I would still then need to pull the changes in my_modules/module1. Yes a step forward from copying files over...
What's the "recommended" way of dealing with this? Any best practices?