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.
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
Currently whenever I make a change to some code I do the following in terminal:
git init
git add .
git commit -m "Some changes"
git push heroku master
I am not 100% certain, but this seems like it is redeploying the entire project and installing all packages again. If this is the case is there a way to only push the changes made?
For example, if I change one line of code, I just want to push that one file with the change, not the entire project again.
It depends how you're packaging the app, e.g. with webpack.config. Typically you'd package and deploy the entire project to the server each time. This is the correct way to do it (rather than just trying to replace one file), so that you can do project-wide actions like minifying code, processing your CSS, etc. The server would not download/install external packages that are already there unless you specify a different version in your package.json file.
git init only be oncethen every time you make a change just run
git add. (add all changes)
git commit -m "commit"
git push origin master
It's because react has to do some of its magic before Heroku can deploy it properly. That magic includes installing the node modules, compiling all the source files, and then optimizing everything before outputting the build folder with everything in it. There's not a 1:1 relationship between the one line in one file you changed and the build output - react requires a re-build.
I am trying to Buddy.works using their CI to upload my themes in in test, staging and production mode.
I have noticed when the files are compiled using Webpack that it is also uploading node_modules to the root folder.
It is taking an age to upload everything. Do I really need those files if the build is finished within Webpack?
Normally working on my project locally all node_modules have to be installed in order to use them. Do I need to include the node_modules in the cloud also?
The standard is to not push node_modules to the SCM(Git, SVN, Mercurial) because they take a lot of space. That's why we have package.json. So on a CI/CD tool like Jenkins, Circle CI or Travis you would specify the build to run npm install --production and it would take care of creating and downloading the necessary dependencies to the node_modules folder.
This makes the build faster too as the first step would be something like,
git clone <repo_url>
If you had pushed your node_modules folder it would take longer to clone due to the extra size.
Does this answer your question?
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'm developing various Angular 2 projects and I want to share node_modules folder between multiple projects. I would like to create a structure like this:
MainFolder
- Project1
- Project2
- package.json
so I would have just 1 package.json for all the projects. My answer: is it possible to do this?
If possible, I have to lunch npm install with -g?
I can't understand how -g works.
Can someone give me instructions how to proceed?
Very thanks
I forgot to say that I build the projects with angular-cli.
The way I go around this for small/learning/test projects is with (I call it) "git projects". Basically I manage the various projects via git, and just "load" the project I want to work on. Of course this doesn't work if you want to have access to multiple projects at the same time.
I like to use a git client for this purpose because it's easier to visualize my existing "projects".
So my workflow is this...
Create my main/base folder. This will contain the git repo, the single node_modules folder, and whatever else that should be common to all projects.
I create the basic package.json file (using npm init). No description, no nothing, just the basic skeleton package.json file. (However, if you know you will use certain packages in ALL of your projects, you can npm install them first, so they will be added to package.json as your "base" modules.)
Now I check the bare package.json into the repo (and anything else that you may want to have in all of your projects, but usually it's just the package.json file). This will be the bare-bones starting branch for all projects.
Once this is checked in, I create a branch off of this in the git repo. This will be "Project 1" - or whatever you want to call it. Then build up your project however you want, installing modules, checking in changes, etc, etc.
When I want to start a new project, I simply check out the first bare-bones project (which is just the empty, or almost empty, package.json file) and do another branch off of it. This will be my 2nd project.
And so forth...
So the main thing is that every new "project" will be a new branch in the git repo, and to create a new project, just switch back to the original bare-bones one and do a new branch off of that.
Of course it is possible to create branches within a project, too. It's all about naming conventions. You could, for example, prefix a new project branch with "P_" or "PROJECT_", etc, so you can quickly tell in your git client which branches are projects. And of course use a different naming scheme if you just need a new branch within an existing project. That's basically how I go about it.
You may not like this workflow, but this way I don't need to install packages globally. When I do a backup, I can simply delete the single (possibly huge) node_modules folder. All project related modules can be reinstalled by simply checking out a branch for a particular project and run "npm install" on its package.json. Hope it makes sense.
Here is documentation on the various npm install arguments
In global mode (ie, with -g or --global appended to the command), it
installs the current package context (ie, the current working
directory) as a global package.
The -g install locations based on environment can be found here
One way you can achieve what you want is to have one solution for both projects and each project route uses it's own lazy loaded module.
Unless you have a specific business need to share resources, it's better to keep each project separate with it own resources and configuration.
-g Stands for global Installation, i.e. the packages you install will be available for all applications.
And why do you want to share node_modules and package.json file?
Keep them seperate for each seperate project. And if you need to share your project, you may share your package.json instead of sharing the node_modules folder.
Also to point out, if you manually install packages by listing their names, then you can use -g (global) flag, but if you do use only npm install then your packages won't be installed as global packages.
If it really is just for testing simple applications, could rename tha app folder in some way provide a solution. It assumes that all the dependencies are the same or at least a subset of the dependencies provided.