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.

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

6. “best” practices

7. “best” practices

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
● …

16. Issues
https://status.npmjs.org/incidents/41zfb8qpvrdj

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

32. Contacts
https://www.linkedin.com/in/anton-cherednikov/
https://www.facebook.com/profile.php?id=100009501190852
https://t.me/a_cherednikov