Publishing Frontend Packages to Private npm Registry
Previously, our team shared frontend base module resources using
Git Submodule, but there were drawbacks. So I spent the weekend researching Nexus npm to switch frontend resources to npm-based maintenance and management.
Drawbacks of Git Submodule
First, let me talk about the drawbacks of using Git Submodule for sharing frontend packages.
Version management depends on commitId. Although submodule has the concept of branches, it essentially depends on commitID. The file storage itself is based on a certain repository and a certain commit. When doing MR code review, if versions are inconsistent, you can’t tell which version is newer just from the hash value. Compared to npm package’s major/minor version numbers, it’s much clearer and easier to understand.
The submodule management approach pulls down all module code, including UT (unit tests), which is actually redundant.
Submodule code in the project is not read-only and can be easily modified. I want code protection with only read permissions.
So, I decided to switch to npm package management. Since our company has deployed a nexus private registry, let me introduce how to publish packages.
Nexus Private Registry Deployment
Since I haven’t learned about Nexus before, let me deploy it locally:
docker run -d --restart=unless-stopped --name nexus -p 8081:8081 -p 5000:5000 -p 5001:5001 -p 5002:5002 -p 5003:5003 -p 5004:5004 --ulimit nofile=90000:90000 -e INSTALL4J_ADD_VM_PARAMS="-Xms2g -Xmx2g" -v /nexus-data:/nexus-data sonatype/nexus3
Configuration
Add three repositories: hosted, proxy, group. In the group repository, drag hosted and proxy into it.
- group refers to repository group, which can include hosted and proxy repositories.
- hosted refers to your own private repository where you can upload private code.
- proxy refers to proxy mirror repository, like the third-party libraries we commonly use such as antd, angular, etc.
Add npm Bearer Token Realm in Realms
Frontend Package Configuration
package.json
"publishConfig": {
"registry": "http://localhost:8081/repository/npm-company/"
},
Note that the repository is npm-company, which is the hosted repository
.npmrc
# auth config
_auth=YWRtaW46YWRtaW4xMjM
always-auth=true
email=hi@1991421.cn
Note: _auth is the base64 encoded result of user:password. This configuration solves password-free publishing, but it’s not the best solution because allowing everyone to publish is dangerous. A better approach is to have the CI server automatically publish after code merge or manually trigger publishing.
Publishing
$ npm publish
Package Usage
In the specific development project’s .npmrc file, add the following configuration:
registry=http://localhost:8081/repository/npm/
Note that the repository is npm, which is the group repository
Common Errors
Unable to authenticate, need: BASIC realm=“Sonatype Nexus Repository Manager”
npm ERR! code E401
npm ERR! Unable to authenticate, need: BASIC realm="Sonatype Nexus Repository Manager"
When this error occurs, it’s usually because the registry is wrong. Pay attention to the registry mentioned above.
Execute npm i alanhg-demo@0.3.0 --save
401 or 404
If you switch npmrc to yarnrc and execute yarn install to install packages, private packages on nexus will fail to install with 401 or 404 errors. The reason should be compatibility issues between yarn and nexus private registry. The current solution is to use npmrc to manage private registry sources.
Failed to stream response due to: Missing blob and no handler set to recover.
Recently when executing package installation commands, the following error occurred:
yarn install v1.22.4
[1/5] 🔍 Validating package.json...
[2/5] 🔍 Resolving packages...
error An unexpected error occurred: "https://nexus.xxxcn/repository/npm/@alanhg%2fui: Failed to stream response due to: Missing blob and no handler set to recover.".
info If you think this is a bug, please open a bug report with the information provided in "/Users/qhe/Documents/GitLab/xxx/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this ⌘.
The solution is to log into the nexus private registry and click invalidate cache.
Final Words
This only sets up the mechanism and solves usage and maintenance issues, but another important issue is package version evolution and package history. If we still use unchanging version numbers or very random version number changes, and each change doesn’t have systematic documentation and records, then it’s still a mess and we still can’t safely and confidently use packages. So we still need to use other tools to manage commit information and project versions properly. Sigh, solving one problem leads to discovering new problems. Don’t be afraid, keep going!
