Publishing Public Packages to npmjs

Previously used the company’s nexus to publish some company-level UI component libraries. Recently wanted to publish the TSRules I summarized in projects to the source, because I want more than just company projects to be able to use them, so decided to use npmjs hosting.

Here I’ll document the publishing process.

Publishing Steps

npmjs Account Registration

Simple, skipping over

GitHub Hosting

Since updates and maintenance are needed, creating a corresponding repository is appropriate.

Click here

File Addition

Since my project only hosts tslint.json, it’s relatively simple overall.

Notes

1. Initialize package.json using npm init
2. For package version management, it’s recommended to use commitizen, standard-version for semantic version control

Package Publishing

npm adduser

# Why add access parameter? See below
npm publish --access=public

Execute the above commands, and when the submission and publishing are successful, it’s done. Through the npmjs website, we can see the published package

Precautions

402 Payment Required

The reason for adding --access=public here is that by default it publishes private packages, and NPM private repositories are paid. If you don’t add this parameter, you’ll encounter 402 Payment Required.

Publish File Whitelist/Blacklist

When publishing packages, there’s often a need to only publish specific files, such as test files/compiled source files, etc. This requires specifying whitelist/blacklist.

1. Use the files field in Package.json for whitelist
2. Use .npmignore for blacklist
3. Use .gitignore for blacklist

Notes

• If files are explicitly specified, they have the highest priority

• If files are not specified but .npmignore exists, then exclude files based on it

• If .npmignore also doesn’t exist, then exclude based on .gitignore

• npm defaults to excluding node_modules when publishing, so no manual exclusion is needed

• The reason for mentioning existence here is that empty files are also considered effective

• package-json.lock or yarn.lock files are ignored during publishing, so if the dependency package versions in this package don’t support modification, they need to be hardcoded. Lock files are only not ignored when used as top-level package version control, so lock files should still be submitted in regular projects - these two points are not contradictory.

Final Thoughts

Previously, every time rules were updated, I had to manually modify multiple libraries to achieve synchronization, which was purely tedious manual labor. This way, I only need to update the rule package version. Each project doesn’t need to directly maintain rule rules, and because there are versions, it also ensures the existence of differences. Cool!