This might be a stupid question but I believe I should know this since I am just starting out in the web development field rather than just assuming. I normally see this
Install via npm or bower (recommended) or manually download the package
or something of that sorts. My Assumption is that the node_module and bower_component updates the packages automatically, however I am not sure.
Sometimes I install with npm or bower, or sometimes I just mannually download the package to which I have seen no difference. Could someone please tell me why it is important to install via npm or bower so I can know for sure what is going on.
Package managers allow you to keep third party code separate from your code and have consistent versions of that code. With npm or bower you can set out exactly what dependencies you project has, and what versions through a single file, without having to bloat your codebase with the dependencies themselves.
This means that anyone who wants to set up the project can just download the core code and run npm install or the equivalent command, and install all the dependencies at the latest supported version.
Related
Everytime I do npm install after cloning a github project OR install packages on my local system for my practice projects, there are always around 20+ vulnerabilities.
But the guys in youtube tutorials always have 0 vulnerabilities.
I even reinstalled npm but it didn't change anything
If you are following an old video, you are likely installing old packages. Therefore it's pretty common to have vulnerabilities.
If you want the warnings to disappear, you can try to remove #version in your packages inside package.json and then run npm i again. Or, as bogdanoff says, run npm update instead.
But be careful: packages may behave differently from the video when updated.
I am studying about npm and I have some questions.
Where the npm get the package from? i.e. when run npm install <package-name> or yarn add <package-name>.
When get the package, do npm get the package as raw or get then build it(like run the build script written in package.json)?
When publish the package, the repository field of package.json is required?
Can be different between the repository for publishing and the repository in pacakge.json?
To answer your questions:
npm gets them from the NPM package registry, and so does yarn, but Yarn probably has a proxy registry in front of it. In general, you can say, both tools fetch their packages from https://npmjs.com by default.
It gets the package as it was published (so, in short, the answer is "raw"). Building is up to the publisher and depends on the type of package. Often, some prepublish task builds something into dist/ (or any other location in the package), and these files are also shipped with the package others then download. Building rarely happens after installing a package (exception here are library-wrapping packages built with node-gyp).
The repository field is not required, to my knowledge, but it is good practise to include it (it will be displayed on the NPM website, for example).
Technically, yes. You can just specify any repository in repository, but it wouldn't make much sense to specify one that isn't the source of the package.
If you in general want to read up more on how npm works, check out it's documentation over at https://docs.npmjs.com/
TLDR: How reliable is an assumption that a compatible version of make is installed on machines that my NPM package will be installed on?
I'm working for a client who is really fond of make and Makefiles. We need to integrate a JS package into another project. My go-to method would be npm install our-package. The package requires a build step. We want to be able to install versions that are not yet released to npm.js from GitHub. The build process is more than one line of shell script so I don't want to repeat it in Makefile and in package.json (it will go out of sync real quick). Straight forward way is to set scrpits.prepare to make in packgae.json. But I'm concerned about cross-platform compatibility (Windows, containers, etc).
Update: I've also discovered that it's extremely easy to create an endless loop where make calls npm ci or npm install and then npm calls make. With npm install there is --ignore-scripts option, but ci doesn't have an equivalent, see: https://npm.community/t/add-ignore-scripts-option-to-clean-install-ci-command/6322
I have a project with a package.json file and an install bash script that, among other steps, runs npm install.
I'm thinking of updating the script so that it runs yarn install if yarn is available (to take advantage of yarn's caching, lockfile, etc), and falls back to npm install otherwise. As far as I can tell, all the packages seem to install and work ok either way.
Are yarn and npm interchangeable enough for this to be a viable approach, though? Or are there potential issues that this could lead to? Are we meant to just pick one, or is yarn interchangeable with npm in practice?
(nb. I've read this closely related question, but I'm asking this as a separate question because it's about explicitly supporting both yarn and npm install processes in a project)
Yarn and npm (version >=3.0.0) should be relatively compatible, especially moving from npm to Yarn, because compatibility is one of the stated goals of Yarn. As stated in Migrating from npm:
Yarn can consume the same package.json format as npm, and can install any package from the npm registry.
So, in theory, any package.json that is valid for npm should also work equally well for Yarn. Note that I say that npm v2 is probably less compatible - this is because npm migrated from a nested node_modules structure to a flat layout (which is what Yarn uses). That said, Yarn and npm v3 should produce very similar layouts, because, as stated in the issue I linked:
To a first approximation we should try to be very compatible with the node_modules layout for people who need that compatibility, because it'll be the most likely way to avoid long-tail compatibility problems.
However, you will not be able to take advantage of the Yarn.lock generated by Yarn, because (as the name suggests) it's only supported by Yarn, and npm shrinkwrap is not compatible.
Also, as noted by #RyanZim, older versions of Yarn don't support pre- and post-install hooks, but versions later than v0.16.1 do. If you rely on these hooks, you will need to specify to users that versions greater than v0.16.1 are required.
In summary, as long as you encounter no bugs and only use features that are shared by both package managers, you should have no issues whatsoever.
I've started using npm for JavaScript package management recently. Although I do have a fair understanding of package management in different environments (let’s say using apt, rvm/gem, and pythonbrew/virtualenv/pip), I don't quite understand how npm fully fits in.
I would like to know more on how the "-g" flag works and why should I use it.
As in most blogs and wiki, they refer to using "-g" when installing without explaining why, and I understand that these packages are installed globally.
But why should I always install these packages globally?
What does it mean to install these packages without the "-g" flag?
What do I do to installed packages locally, let’s say sandboxed for different projects?
How can I then, make a list of npm packages used in a project and bundle it in the project if I needed it to check it in with version control (if possible at all)?
-g is the global install flag, as explained in this answer. It's covered in detail in this node blog post.
The rules of thumb:
Install globally if the package provides command-line tools
Install locally if you're using the package as part of your application
Install globally and locally if both use-cases apply
While the accepted answer is correct, be aware that there is also npx which allows to conveniently run local tools.
For more information, see Introducing npx: an npm package runner