Modules and artifacts in NPM by Anton Cherednikov
0 likes155 views
The document discusses best practices for managing npm modules and artifacts, emphasizing the importance of versioning, dependency management, and the use of both public and private registries. It covers topics such as publishing, maintaining modules without issues, and implementing CI/CD processes for efficient development. Additionally, it highlights the challenges of relying solely on public registries, along with recommendations for constructing a robust package management strategy.
Modules and artifacts in NPM by Anton Cherednikov
- 1. Modules and Artifacts in NPM ANTON CHEREDNIKOV Summer. Sea. JavaScript.
- 2. Agenda ● Artifacts and Modules ● why? ● decomposition ● examples ● “best practices” ● publish ● Maintain modules without pain ● audit, versioning, dependencies, expectations... ● Registry ● issues, public/private registry, alternatives... ● CI / CD
- 3. Why? ● Isolating components that are duplicated: ○ service core library ○ logs ○ utils ○ db models ● Own corporate / project standards ● Flexibility in development ● Using the advantages of versioning convenience
- 4. Decomposition ● Libraries provide a way to share functionality with different teams and services. ● (!) Shared code can be a point, which will create an dependencies between services (ex .: ORM DB models) ● Service-core library: an approach that allows you to create some kind of standards for your micro-services
- 8. Publish ● configure package.json ● describe README.MD ● set default credentials: $ npm adduser / npm login ● tap $ npm publish ● enjoy: $ npm i %package_name%
- 9. Maintain modules without PAIN
- 10. Audit ● review your package: $ npm publish --dry-run ● or just use $ npm pack to see result ● describe the entries to be included when your package is installed as a dependency, use files property (package.json) ● take care of your dependencies: $npm audit/outdated
- 11. Semantic Versioning ● MAJOR version when you make incompatible API changes ● MINOR version when you add functionality in a backwards-compatible manner ● PATCH version when you make backwards-compatible bug fixes.
- 12. Dependencies ● ^version “Compatible with version” (by default: $ npm i %package_name%) ● version Must match version exactly ● ~version - Approximately equivalent to version ● >version Must be greater than version ○ >=version ○ <version ○ <=version ● * Matches any version
- 13. Expectations ● Any project structure ● Description required (wiki, REAME.MD) ● Tests - is a must ○ coverage control ○ reports ○ automated ● Use the advantages of versioning ● All that can be automated - should be automated
- 14. Registry Motivation to use private registry
- 15. Issues ● Public registry returns 404 for a package installed before ● https://status.npmjs.org/ ● https://status.yarnpkg.com/ ● Many packages suddenly disappeared (all dependencies of webpack-related modules): ● https://www.npmjs.com/package/infinity-agent ● https://www.npmjs.com/package/timed-out ● https://www.npmjs.com/package/pinkie-promise ● https://www.npmjs.com/package/require-from-string ● …
- 17. 23 March 2018
- 18. left-pad Left-pad module - is an example of unexpected behavior of public registry. 23 March 2018: React, Babel, and a bunch of other popular NPM packages broke. A simple NPM package called left-pad was installed as a dependency in React, Babel, and other packages. The owner just remove it from npm. RIP. Azer Koçulu - left-pad creator left-pad: O(N^2)
- 20. Public and private registry ● default: registry.npmjs.org ● public (may do anything with any dependencies) ● private: ○ MyGet (https://www.myget.org) —which costs US$ 9/month for starter plan and you only would have 2 contributors and 1GB storage ○ NPMJS.COM (https://www.npmjs.com) — which costs US$ 7 per user per month. (Organize packages and teams into permissions groups) ○ * Custom solution
- 21. Alternative ● npm install --save username/repo#branch-name ● Static repository url ● Authentication required ● Private repository: IP whitelist config required ● We don’t use registry
- 22. ● If you want to use all benefits of npm package system in your company without sending all code to the public, and use your private packages just as easy as public ones. ● Out of the box with its own database ● Caching the downloaded modules ● Mirroring (proxy) other registries ● Secure. Supported npm/yarn audit ● Supported Installing packages (npm install, npm upgrade) and publishing packages (npm publish) simple, zero-config-required local private npm registry https://github.com/verdaccio/verdaccio $ npm install --global verdaccio $ npm set registry http://YOUR_DOMAIN.COM/ $ npm publish --registry http://YOUR_DOMAIN.COM/
- 23. ● Full support for managing npm packages and ensures optimal and reliable access to npmjs.org ● Mirroring (proxy) ● Aggregating: access to multiple npm registries from a single URL. (overcomes the limitation of the npm client which can only access a single registry at a time) ● Assign access privileges according to projects or development teams.
- 25. CI CD
- 26. npm ci ● NPM 5.7.0 introduced the new npm ci command ● it’s faster — some report a 2–5x speed improvement of their CI ● it only considers package-lock.json (make sure the file is checked in) ● it never updates package.json or package-lock.json ● it throws away existing node_modules and starts with a clean slate $ npm install added 184 packages in 12.103s $ npm ci added 184 packages in 5.922s * use it when you cook your container
- 27. npm ci benchmark
- 28. Basic CI/CD flow ● unit tests - run on each commit. Quality control. ● manual publish - publish npm module to artifactory. Manual action. Appends a prefix to the artifact name ● manual unpublish - remove npm module from artifactory ● autopublish - triggered only when changes were merged in master. Publish npm module to artifactory without any prefixes
- 30. Summary ● Choose the right solution for each individual situation (git dependency, public/private registry, registry provider...) ● Avoid public registry ● Audit your packages (versioning, dependencies, scheduled checks…) ● Collect old artifacts ● Build process of deployment your npm modules with a team (example: prefix for development modules, publish/unpublish package terms) ● All that can be automated - should be automated: CI / CD
- 31. THANK YOU