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
Related
I'm referring to the standalone installation from GitHub and adding it to PATH vs. npm install -g sass. Both are Dart Sass, but the npm version is compiled to pure JavaScript.
The official installation instruction says that Sass installed through npm is slower than a standalone installation (from GitHub and adding it to your PATH). Is this referring to performance when compiling locally? Would it have an impact on end-user performance?
What about the productivity? Is npm faster and easier to install, as well as easier to add to a project? Can I install it globally while also using the --save flag to add it as a dependency to the project?
Are there any other implications of choosing one over another?
Should I need to do a npm install for SPFX if I have already done a global install of all the modules required by SPFX?
Restoring modules is very slow, and I'd really like to avoid doing it if necessary.
To get started coding faster you can start yeoman like this in CMD:
yo #microsoft/sharepoint --skip-install
Open project in preferred IDE, for example VS Code and start coding with:
code .
Start npm install in background with:
npm install
Continue coding in your IDE while npm installs in the background!
I do not recommend to install all spfx packages global. Each project can use different versions of packages. And for each project there is separate node modules folder used to build and package solution. Maybe there is a way to point build and package from globally installed packages but as i wrote there could be huge differences between versions ... just run npm i and take a coffee 😉
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.
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.