What is the best way to edit an NPM package to have my own code but still be updated with the package (But not overwritten, kind of like git merge).
Attempt 1:
So right now I cloned the Git repo to a folder and in my package-json I declared the dependency to require that folder..
{
"dependency": "file:lib/dependency"
}
And what I also did was add the origin to my personal Git repo and add the upstream as dependency's original repo. The idea here is that when the maintainers update the original repo I can pull the upstream and when I wanna push my personal changed code I can push to origin.
Please let me know what you think of this approach and if there's anything I'm doing wrong or should do different. Thanks in advance.
Related
When I run "npm install" in a project it often modifies package-lock.json, for example if I work on the same project from another computer (with different node or npm version).
But at the same time the documentation suggests that the file is supposed to be added to version control (git in my case):
https://docs.npmjs.com/files/package-lock.json
This file is intended to be committed into source repositories, and
serves various purposes: ...
So should I commit the changes made by npm back and forth when switching work machines or when somebody else does npm install? This would be a nightmare.
Currently I just discard any changes to package-lock.json made by npm, and it's been working fine. So I might as well add it to .gitignore...
Am I doing it wrong? Should I use npm ci instead? I wouldn't call my computer a "CI", it's just a development machine, why should I use it there?
Basically I have the same question as this gentleman:
https://github.com/npm/npm/issues/18103#issuecomment-370401935
(Sadly I can't add a comment on that issue or create a new issue at all, the npm repo has issues disabled)
Yes you want to commit your package-lock.json file to source control. The reasoning behind this is to ensure that all of the same versions of each package are downloaded and installed for each user that pulls down the code. There are some other reasons to include the file such as tracking changes to your package tree for auditing.
For a particular npm package I want to create a PR with some code changes.. The author of the package told me, to create a PR from a particular branch..
All fine so far, I can change the url + branch inside the package.json and load the specific branch as npm module.. Also npm install works fine.
But then I want to change some code in that node_modules/module folder and create a PR from the code changes..
The only thing I can make to work for sure, is to first fork the entire repo in a separate folder, than checkout X branch, than change code, copy/past it to the node_modules/module folder every time I wanna check my code changes.. And than push it to my personal github page, and from there create a pull request..
But its really frustrating to copy/past my changes every time to the node_modules/module folder.
What is the best way to change a npm package and create PR for it, while still keeping the code inside the node_modules folder, so code changes can be checked?
Thanks!
This is the proper thing to do. Fork the github repo, create the branch that the guy told you, make the changes and send a pull request.
If you want to work in parallel and assuming that there are no compilation steps that npm should do, you can clone the forked repository within your node_modules and work directly there. As soon as you will make and commit the changes then you can send the pull request.
EDIT
I would say that this can be an acceptable approach that can work on linux:
~/projects/your-project/node_modules
~/projects/your-project/node_modules/name-of-module (symlink to the ~/projects/your-forked-cloned-repo)
~/projects/name-of-module (It should be your forked repo that you 've cloned from github/assembla etc)
~/projects/node_modules (symlink to the ~/projects/your-project/node_modules)
You're looking for npm link:
$ git clone your/npm-repo-fork
$ cd npm-repo-fork
# Link the project as a local dependency
$ npm link
$ cd ../some/other/project
# Use the linked project
$ npm link name-of-npm-dependency
# Now you can edit npm-repo-fork and the changes
# will be picked up by some/other/project
$ cd ../../../npm-repo-fork
i've a repo with master and branch1. I'm writing test in branch1 with mocha / chai and i've changed the package json (forked a repo and maded some changes to it), but Travis seems to build still the old one, even if i changed my package.json. I've just forked and replaced the version in the package.json with the name of the repo (like everytime).
Anyone have experienced something similar? I'm missing the right way to make Travis build the package.json that is in the Pull Request where i'm working?
just trying to clarify some things in your question :)
Are you submitting a pull request to the upstream repo that you forked from, and wanting the upstream repo's Travis integration to build your code?
If so, it may be that the upstream repo's maintainer doesn't have the "Build PR" setting turned on in Travis for their repo. You could ask them. See this question for more details. Or maybe your PR can't be merged, as described in the Travis docs.
Or are you working on a branch within your own repo, which you forked from upstream?
If so, you need to set up Travis integration yourself on your own forked repo.
I solved my problem specifing in the package.json the commit id of the node module. Probabily not the best way to accomplish this, but the test passed now.
I'm using npm link as described here
http://npmjs.org/doc/link.html
Locally everything works perfectly. When I deploy to Heroku I get the error message
Error: Cannot find module '...'
How can I get this working with Heroku?
I wish there were an elegant solution to this (it would make my life a hell of a lot easier). Your custom package is symlinked into node_modules by npm link, but git doesn't follow symbolic links nowadays. So when you git push to Heroku, there's no way to make your custom packages go along for the ride.
Note, however, that from my experiments, Heroku will honor any node_modules you do push in, instead of trying to install them from the network. It just runs npm install --production, essentially. Perhaps a hard link directly to the development source of your package would do the trick, but I'm not sure whether Git would play nicely with that. Use at your own risk!
EDIT: If you want to know exactly what Heroku does, it's all open source.
The ideal situation would be to get the packages, if they're open source, onto NPM itself. Which is pretty painless and automatic.
If you are hosting your private module on GitHub (or BitBucket), you can add the git repo as a dependency in your package.json.
"dependencies": {
// ... all your deps
"my_private_module": "git+ssh://git#github.com:my-username/my-private-module.git"
}
You will, however, need to grant privileges to Heroku to read your repo (assuming it's private -- which is the crux of the issue). Check out this answer for a detailed set of instructions showing how to do so with Github. This might help for Bitbucket.
I've found that the build time increases when doing this. Worth it for my needs.
I am managing a dependency at Github which I use as a dependency in my project. I placed the dependecy as a tarball link (viz. https://github.com/username/dependecy/tarball/master) into the package.json and it is working fine as expected locally. When I update the package at Github I can run a npm install and all dependencies including the Github tarballs get updated. However it is not the case at Heroku. tarball-linked dependencies does not get updated. Any ideas?
I had the similar problem. My App had the dependency with caret versioning like this:
"dependency": "^0.6",
So every time the dependency got its patch version updated, I wanted Heroku to have the updated dependency without any commits/pushes to my App. For that I set just in case
heroku config:set NODE_MODULES_CACHE=false
And when the new patch version became available I did the manual redeploy of the same App that was already deployed from Heroku Dashboard.
Can you try to do the same for your case? Possibly this will help you.
Since no one has answered this yet I will share what I have learned. The trick is getting heroku to think the tarball is different or new so that it downloads it again. As #celalo suggested you can remove it or change the path, commit, push, change it back, commit and push. This is messy but it works.
What I ended up doing was making a master1 branch. I keep the branch in sync with master and then alternate the tarball url between master and master1 when I need it to update.