I've got a task that involves writing a code and I carried it out quite easily. I need to submit my solution to GitHub – according to the plan, I forked a certain repository and even cloned it to my hard drive using VS code. However, I was also told to install NPM dependencies to that newly created folder.
There are many manuals on Internet, but almost no one of them explains how to do it in a comprehensible way. As a beginner, I often struggle with all these new keywords, commands, etc and I would like to make things somewhat clearer. Do you have an idea how to get through it?
If you have already installed npm, in project directory use command
npm install
You can start with npm init in your folder. Then package.json file will be created. you can add dependencies you want to add, and run npm install.
Related
In a team set up, usually, I have faced merge conflicts in package-lock.json and my quick fix has always been to delete the file and regenerate it with npm install. I have not seriously thought about the implication of this fix because it has not caused any perceivable problem before.
Is there a problem with deleting the file and having npm recreate it that way instead of resolving the conflicts manually?
Yes, it can and will affect all the project in really bad way.
if your team does not run npm install after each git pull you all are using different dependencies' versions. So it ends with "but it works for me!!" and "I don't understand why my code does not work for you"
even if all the team runs npm install it still does not mean everything is ok. at some moment you may find your project acts differently. in a part that you have not been changing for years. and after (probably, quite painful) debugging you will find it's because of 3rd level dependency has updated for next major version and this led some breaking changes.
Conclusion: don't ever delete package-lock.json.
Yes, for first level dependencies if we specify them without ranges (like "react": "16.12.0") we get the same versions each time we run npm install. But we cannot say the same about dependencies of 2+ level deep (dependencies that our dependencies are relying on), so package-lock.json is really important for stability.
In your case you better do next way:
fix conflicts in package.json
run npm install
As easy as it looks. The same to yarn - it fixes lockfile conflict on its own. The only requirement here to resolve all the conflicts in package.json beforehand if any.
Per docs npm will fix merge conflicts in package-lock.json for you.
[Upd from 2021] important! If you use some library already and npm/GitHub account of its maintainer is hacked. And new version with malicious code inside is released. And you have package-lock.json intact. You will be fine. If you drop it you are in trouble.
Yes it can have bad side effects, maybe not very often but for example you can have in package.json "moduleX": "^1.0.0" and you used to have "moduleX": "1.0.0" in package-lock.json.
By deleting package-lock.json and running npm install you could be updating to version 1.0.999 of moduleX without knowing about it and maybe they have created a bug or done a backwards breaking change (not following semantic versioning).
Anyway there is already a standard solution for it.
Fix the conflict inside package.json
Run: npm install --package-lock-only
Check out this link for more info:
https://docs.npmjs.com/cli/v6/configuring-npm/package-locks#resolving-lockfile-conflicts
I know it's an old question but for future seekers, you can also use npm-merge-driver which try to automatically resolve the npm related files' merge issues.
Just install it globally npx npm-merge-driver install --global. You can read more about it here npm-merge-driver
Edit: Just want to warn people, who are interested in using above package, that sometime it can behave erratically and difficult to remove. So although it is a useful tool, it still need some work.
Edit: This repository is now archived and read only.
npm i --force does the work for me
I'm a little confused as to why I can't get my Gruntfile.js to run, here's the rub:
I installed grunt globally using npm. It lives in my /usr/local/bin/ directory, here it is:
Previously, I'd installed node.js using homebrew, then grunt with npm. Other issues led me to uninstall node via homebrew & reinstall node directly from the disk image node provides.
In my web project's index, there's a Gruntfile.js script that rebuilds my jekyll site everytime live-reload updates. When I run grunt, I get this message:
What I'm trying to wrap my head around:
Why isn't /usr/local/bin/grunt a valid path? Grunt exists at that location. My guess was that running grunt locally, from within my website's index, would fix things.
There's a node_modules folder there & everything was working fine before after all. I found this link, and tried running \grunt to bypass the bash alias, but that had no effect.
Any advice/suggestions are much appreciated! I feel like an imbecile using things, breaking things & not understanding why/how. Eager to finish my project, get a paycheck & finally have time to learn the ins and outs of terminal, bash & popular package managers so I don't run into these sorts of problems...
After discussion with OP, I find this is a Node.js environment issue. After install - do something - uninstall - reinstall in another way - do something, somehow, when npm install -g XXX is executed, the symbolic link is created and point to some place, but the package is installed some where else. That's why OP see /usr/local/bin/grunt but cannot run it.
I've recommended OP to clean up all Node.js stuff, make a clean environment and start right from the beginning.
The setup/workflow:
Project A relies on a custom npm package in package.json.
As engineers work on Project A, they will inevitably be making changes to the custom npm package as well. This is streamlined by having them clone down both the project and custom package repos, then applying npm link.
(source: http://justjs.com/posts/npm-link-developing-your-own-npm-modules-without-tears)
The question:
Assume a developer has now finished making changes to both Project A and the custom npm package. Here are the next steps:
He or she must submit a Pull Request for the custom package and wait for it to be code reviewed and merged.
He or she must now open Pull Request for Project A, containing a bumped version number on the custom package in package.json.
This feels clunky and prone to blocking our other developers.
Does anyone have suggestions for a better workflow when building a custom npm package and a project that depends on it at the same time?
What I do is use username/repo#branch as the version in package.json. This causes npm to pull directly from my fork on GitHub, bypassing the npm registry. I tend to only do this when I cannot wait for the maintainer to publish a release to the npm registry (not that often for me).
When the maintainer publishes a release to npm then I update the version number to the new release. Also, I would not include the version number in a pull request, I would always let the maintainer(s) decide how to bump the version.
So you have project A depending on package B. First, if B is under rapid development, it does not make much sense to make A dependent on B (by listing it in package.json and 'npm install'-ing it): it'll bring you more pain than gain. Instead of this, copy B directly into the A and use it directly (without using any npm machinery).
Only when B's API gets stable enough, publish it as a separate module and depend on it npm way.
But this is not all! To keep things reasonably separated and decoupled, you should use git submodules.
https://git-scm.com/book/en/v2/Git-Tools-Submodules
This great feature of git allows you to put one git repo inside another git repo. This way, both of your projects are reasonably well decoupled; also this makes the process of publishing B as a separate unit much easier.
I've tried both approaches ( a) npm with git branch dependency vs. b) git submodules, no npm) on two separate middle-sized projects and I enjoyed the submodules way much more :)
I think one possible solution is to be more generic with the versioning in Project A's package.json.
Instead of explicitly maintaining the version number of the custom npm module dependency, we can use asterisks in the semvar statements.
Eg:
"#org/custom-node-module": "0.1.2" - requires manually changing everytime the npm package is updated.
"#org/custom-node-module": "0.*.*" - running npm install will always grab the most recent non-breaking version.
Is it ok to have a node.js project with no package.json? The ones I see on the internet all come with package.json
What is the effect of having no package.json?
How is package.json created in the first place? Is it created automatically? I am wondering why I do not have package.json
Fundamentally, package.json is a meta file for your application. It lists all the configuration of your application.
What is the effect of having no package.json?
Nothing as far as you're running all your code locally and have no requirement for deployment whatsoever.
Let's setup a scene for you to understand this better.
Imagine that you wrote a brilliant application using node. Now all the chicks in your surrounding want it to play with. It is so fantastic!
Now you want to give it to them and during the development process you `npm install`ed so many things that your project grows beyond 4TB size.
There is no data storage device available to ship that huge code base.
Then the girl of your dream said I want it and I want it now. So you begin searching for app deployment process for node applications.
That is where you stumble upon a magical thing called package.json.
So what you do is you list all your npm installed modules under dependencies property. Then you delete node_modulesfolder, add package.json and commit the entire damn thing in github. Even the .zip file is of 10MB
Then she gets the code.
Types in npm install && npm start (which will install all the dependencies from the package.json` and start your application)
If you have package.json however, that is where you specify all your dependencies.
Using --save flag of npm install
Example.
npm install express --save
How is package.json created in the first place? Is it created automatically?
You can manually create a text file and save it as package.json
OR
A more sophisticated way is to use the command
npm init
I am wondering why I do not have package.json
Me too! :)
You're most probably following a tutorial that doesn't emphasize on initial configuration of the project OR the author of those tutorials presume that the reader has all the fundamentals down to begin with.
It is created automatically if you write npm init.
Then, every package you add using npm install packagename --save will be added to the dependencies list.
You need package.json so that when you want to use your project on another machine you don't have to copy all node_modules, but only your .js files you have written, assets and package.json. You can then run npm install command and it will automatically download and install all the required modules (found in the list of dependencies inside package.json).
You can also manually create or edit it, but it's easier to add --save when installing a module so you don't have to worry about package versions and stuff like that.
Also if you want to create a npm package, an open source project or stuff other people will use, it's either required or the norm to have this package.json file describing your project.
package.json is npm file, if you don't use npm you will not have this file, npm is a great tool if you want to use external libraries in your project but if you don't need it (which is very not likely unless you are doing something very simple), you don't need package.json file too.
To generate package.json file initialize npm in your project using npm init
possible reason thus it exist is you maybe you enter a wrong command like npm i -y, you must initialize the project first, just enter a command npm init -y
Welcome.
Well, if you are running it on your local machine, it's fine. now to answer your last question, package.json is not created automatically.
the npm command npm init -y creates the 'package.json' file. It basically makes sharing your code and installing your codebase easier.
I'm trying to create a custom build with core-js. Per the documentation, I first ran
npm i core-js && cd node_modules/core-js && npm i
which seemed to be fine. Then, also per the docs I tried
C:\GIT\coreJS_Custom\node_modules\core-js>npm run grunt build:es6.array.from -- --library=on --path=custom uglify
and lots of variations on that theme. It seems to run briefly, with no output at all, and I can't seem to find any generated file. What am I doing wrong?
Also, the above commands were run on the Windows 8.1 cmd terminal.
What's particularly interesting (and frustrating) is that running this
C:\GIT\coreJS_Custom\node_modules\core-js>npm run grunt kjhgjhghkghh
Similarly runs briefly and then seems to succeed.
I'm not sure what my root problem is, but for me, running the grant task on its own, without npm run did the trick
So something like this should be the final product.
C:\GIT\coreJS_Custom\node_modules\core-js>grunt build:es6.array.from --library=on --path="es6-array-from-build-min2" uglify