- 1. Setting up an NPM Organization
- 2. Making a new private npm package
- 3. Importance of Tests and Documentation
- 4. Using a private NPM package
- 5. Publishing a private NPM package from the terminal
- 6. Publishing a private NPM package though a CI Pipeline
- 7. Installing a private NPM package in a CI Pipeline
- 8. Serverless Guru's Opinionated Approach
- 9. Strategies for managing dependencies in Private NPM packages
- About Scopes
- About Private Packages
- Package Naming Guidelines
- Creating and Publishing Private Packages
- How to work with Private NPM Packages in a CI Pipelines
- Only have 2 groups:
- developers (default group)
- ReadAccess: Every Private Module
- WriteAccess: Nothing
- Includes: Everyone
- publishers
- ReadAccess: Every Private Module
- WriteAccess: Every Private Module
- Includes: Only 1 member designated as the publisher
- developers (default group)
Have a master branch which rapidly gets merged into as development takes place. Each merge into master should kick off a pipeline which runs tests
Have a release branch which only gets merged into from master when we want to publish a new version of our npm package. This pipeline process will assume an NPM TOKEN which represents the permissions of the one member who is inside the publishers NPM team.
When setting up our teams and pipelines in this way, we can decide who gets to publish, who doesnt, when it happens, under which circumstances it happens in the context of our branching strategy. This allows us to centralize permissions and decision making here rather than on multiple platforms.
The alternative is to manage NPM teams and keep track of who has permissions to what on which npm package.
It is important to have our private NPM packages well documented so others within our company can use them easily. Important sections to have are:
- Installation Instructions
- API documentation for the package
- Examples of how a developer could use this package in their code
Example Documentation for a Private NPM Package
- when you are solving a common problem others will be solving in other services
- when you don’t want to write what you have written again
- when what you are writing is stable
- when what you are writing is generic