Original Address https://github.com/jindada/blog/issues/1

Why private NPMS need to be built

• Private packages only want to be used internally, not git+ssh, feel less elegant, and configure the appropriate permissions
• Packet download on npm is very slow. To cache the downloaded packages on the server, first check for updates on the next download. If no updates go directly to the cache
• When you want to download, the public take out the public warehouse and the private take out the private warehouse of the internal server

Why write this article

When writing this article, I have seen several good articles written by the gods. Here I want to summarize them and explain the pits that are not mentioned in the existing articles.
Here's a list of articles that feel good:
+ Build a private npm repository using Sinopia
+ Sinopia | Build npm repository from scratch

Introduction to sinopia

sinopia The introduction, advantages and disadvantages do not detail the above two articles have a very detailed description

Deployment Installation and Use

Install sinopia and start up (assuming you have already installed the node environment)

$ npm install sinopia -g
$ sinopia

Then open the browser to access the address http://localhost:4873/Normal display succeeds, 4873 is the default port

Configure npm proxy

After the sinopia is started, the npm proxy used by the client is first set by npm set registry http://localhost:4873/and then it can be used properly

Add users and login

$ npm adduser --registry http://localhost:4873 // Enter as prompted

$ npm login // Enter as prompted

After successful login, you can execute npm publish and publish to this private npm. Refresh http://localhost:4873/You can see the package you just uploaded.

To configure

Sinopia is characterized by the directory in which you run it, and it creates its own files in the corresponding directory.Without specifying a configuration file, the default directory is the installation directory. You can specify the directory to run through sinopia-c path/config.yaml

There are two files in the directory by default: config.yaml and storage, and htpasswd is created automatically after adding users.

config.yaml: Configure all configuration information such as access rights, proxies, file storage paths, etc.

# This is the default config file. It allows all users to do anything,
# so don't use it on production systems.
#
# Look here for more config file examples:
# https://github.com/rlidwka/sinopia/tree/master/conf
#

# path to a directory with all packages
storage: ./storage  // Path to store npm packages

auth:
  htpasswd:
    file: ./htpasswd   // Save information such as user's account password
    # Maximum amount of users allowed to register, defaults to "+inf".
    # You can set this to -1 to disable registration.
    max_users: -1  //Default to1000，Change to-1，Prohibit registration

# a list of other known repositories we can talk to
uplinks:
  npmjs:
    url: http://registry.npmjs.org/ //Official network defaulting to npm

packages:  // Configure Rights Management
  '@*/*':
    # scoped packages
    access: $all
    publish: $authenticated

  '*':
    # allow all users (including non-authenticated users) to read and
    # publish all packages
    #
    # you can specify usernames/groupnames (depending on your auth plugin)
    # and three keywords: "$all", "$anonymous", "$authenticated"
    access: $all

    # allow all known users to publish packages
    # (anyone can register by default, remember?)
    publish: $authenticated

    # if package is not available locally, proxy requests to 'npmjs' registry
    proxy: npmjs

# log settings
logs:
  - {type: stdout, format: pretty, level: http}
  #- {type: file, path: sinopia.log, level: info}

# you can specify listen address (or simply a port) 
listen: localhost:4873  // Default no, can only be accessed locally, change localhost to0.0.0.0It can then be accessed via an external network

htpasswd configuration

max_users: -1 in config.yaml means we set the maximum number of users to -1, which means we disable the npm adduser command to create users, but we can still initialize users by opening htpasswd files in the directory

zhangsan:{SHA}?????????????????=:autocreated 2016-02-05T15:33:46.238Z
lisi:{SHA}????????????????=:autocreated 2016-02-05T15:39:19.960Z
wangwu:{SHA}????????????????=:autocreated 2016-02-05T17:59:05.041Z

It's obvious that the password is encrypted, but the encryption algorithm is simple: simply SHA1 hashing, then converting to Base64, followed by a time stamp.
Even so, we are still confused, or don't know how to add users?Don't be afraid!! Here's a useful plugin for everyone. htpasswd-for-sinopia Yes, it was written by the author himself. Everyone thinks it's good to have a star.Here is a brief description of the usage of htpasswd-for-sinopia:

$ npm install htpasswd-for-sinopia -g // install

$ sinopia-adduser // Execute in the sinopia directory and enter the username password as prompted

$ vim htpasswd // Check htpasswd and find that the information you just entered is lying quietly in it, which proves that it was added successfully

packages configuration (as detailed in the previous article, here's a direct copy)

The configuration is roughly divided into two parts, one starting with @weflex/* and the other with a wildcard *.

This, of course, is to match the name field in package.json, for example, @weflex/app will match the first configuration and express will match the second.

The implication of this configuration is that, in general, private projects of a team or company are controlled with different privileges, so NPM scoped name s are borrowed here in the form of @company, for example @weflex/app for app projects under WeFlex.

Next, there are three basic settings under each named filter:

access: Indicates which type of user can install a matching project
Publish: Indicates which type of user can publish matching items (publish)
proxy: If its name, the value here corresponds to uplinks
For values 1 and 2, we usually have the following optional configurations:

all means that everyone can perform the corresponding action authenticated means that only authenticated people can perform the corresponding action
$anonymous means that only anonymous people can perform corresponding operations (usually useless)
Or you can specify one or more users in the user table htpasswd that corresponded to the previous configuration, so that you can explicitly specify which users can perform the matching operation configuration before running:

$ sinopia -c config.yml

Use with sinopia

pm2: Process Daemon Management Tool

$ npm install -g pm2

$ pm2 start `which sinopia`

More Operational References https://wohugb.gitbooks.io/pm2/content/

nrm:npm Mirror Address Management Tool

$ // Install nrm
$ npm install -g nrm
$ // view list
$ nrm ls
$ // Add a mirror named sinopia
$ nrm add sinopia http://localhost:4873
$ // view list
$ nrm ls
$ // Use the mirror address of sinopia
$ nrm use sinopia

Security

To ensure a private npm repository, you can add a layer of Nginx to the front end and configure SSH as a two-tier validation