Npm: Unterschied zwischen den Versionen
| Zeile 23: | Zeile 23: | ||
npm run [scriptname in package.json] | npm run [scriptname in package.json] | ||
npm view [paketname] | npm view [paketname] | ||
| + | == package.json == | ||
| + | Todo | ||
| + | === package-lock.json === | ||
| + | https://stackoverflow.com/questions/44297803/what-is-the-role-of-the-package-lock-json | ||
| + | It stores an exact, versioned dependency tree rather than using starred versioning like package.json itself (e.g. 1.0.*). This means you can guarantee the dependencies for other developers or prod releases, etc. It also has a mechanism to lock the tree but generally will regenerate if package.json changes. | ||
| + | |||
| + | To answer jrahhali's question below about just using the package.json with exact version numbers. Bear in mind that your package.json contains only your direct dependencies, not the dependencies of your dependencies (sometimes called nested dependencies). This means with the standard package.json you can't control the versions of those nested dependencies, referencing them directly or as peer dependencies won't help as you also don't control the version tolerance that your direct dependencies define for these nested dependencies. | ||
| + | |||
| + | Even if you lock down the versions of your direct dependencies you cannot 100% guarantee that your full dependency tree will be identical every time. Secondly you might want to allow non-breaking changes (based on semantic versioning) of your direct dependencies which gives you even less control of nested dependencies plus you again can't guarantee that your direct dependencies won't at some point break semantic versioning rules themselves. | ||
| + | |||
| + | The solution to all this is the lock file which as described above locks in the versions of the full dependency tree. This allows you to guarantee your dependency tree for other developers or for releases whilst still allowing testing of new dependency versions (direct or indirect) using your standard package.json. | ||
| + | |||
| + | NB. The previous npm-shrinkwrap.json did pretty much the same thing but the lock file renames it so that it's function is clearer. If there's already a shrink wrap file in the project then this will be used instead of any lock file. | ||
== Sicherheit == | == Sicherheit == | ||
Kann auf dem Rechner skripten, daher sind Sicherheitsprobleme möglich. | Kann auf dem Rechner skripten, daher sind Sicherheitsprobleme möglich. | ||
Version vom 3. Februar 2022, 19:35 Uhr
Siehe auch Yarn
- Node Paket Manager
- Wird von NodeJS verwendet, bzw. NodeJS bringt ihn gleich mit.
- Nützlich auch für nicht-Node Projekte
- Viele JavaScripte z.B. Plugins von jQuery kann man nur noch über npm holen.
Links
Packages suchen: https://www.npmjs.com/search Website - Go live
Hinweis
Wenn npm global mit homebrew auf MacOs installiert ist kann es später zu vielen ENOENT Fehlern kommen. Die Fehlerbehebung ist nicht mehr npm manuell zu installieren wie es zum Teil im Netzt steht. Besser einfach homebrew aktualisieren und node de und wieder installieren.
Snippets
npm install [options] paketname npm install [paket]@2.3.4 npm cache clean npm list npm list -g npm run [scriptname in package.json] npm view [paketname]
package.json
Todo
package-lock.json
https://stackoverflow.com/questions/44297803/what-is-the-role-of-the-package-lock-json
It stores an exact, versioned dependency tree rather than using starred versioning like package.json itself (e.g. 1.0.*). This means you can guarantee the dependencies for other developers or prod releases, etc. It also has a mechanism to lock the tree but generally will regenerate if package.json changes.
To answer jrahhali's question below about just using the package.json with exact version numbers. Bear in mind that your package.json contains only your direct dependencies, not the dependencies of your dependencies (sometimes called nested dependencies). This means with the standard package.json you can't control the versions of those nested dependencies, referencing them directly or as peer dependencies won't help as you also don't control the version tolerance that your direct dependencies define for these nested dependencies.
Even if you lock down the versions of your direct dependencies you cannot 100% guarantee that your full dependency tree will be identical every time. Secondly you might want to allow non-breaking changes (based on semantic versioning) of your direct dependencies which gives you even less control of nested dependencies plus you again can't guarantee that your direct dependencies won't at some point break semantic versioning rules themselves.
The solution to all this is the lock file which as described above locks in the versions of the full dependency tree. This allows you to guarantee your dependency tree for other developers or for releases whilst still allowing testing of new dependency versions (direct or indirect) using your standard package.json.
NB. The previous npm-shrinkwrap.json did pretty much the same thing but the lock file renames it so that it's function is clearer. If there's already a shrink wrap file in the project then this will be used instead of any lock file.
Sicherheit
Kann auf dem Rechner skripten, daher sind Sicherheitsprobleme möglich.
Sichere Konfiguration:
npm config set ignore-scripts true
FAQ
Ich bekomme viele Warnungen wegen deprecated etc. wenn ich z.B. npm install --save-dev gulp auführe.
Normalerweise nicht schlimm und man kann nicht viel daran machen. http://stackoverflow.com/questions/38227112/installing-gulp-gives-me-these-warnings Bei Problemen kann man
