Package.json of project development

Name

must field.

Tips:

• Do not include the word JS, node in name;
• The name cannot begin with a dot or underscore;
• This name cannot contain uppercase letters;
• This name may be called in the Require () method, so it should be as short as possible;
• The name field cannot contain non-URL-safe characters because it will be written to the URL as the information about your package when it is published, so what are non-URL-safe characters?

Version

must field.

For "version": "x.y.z" 1. Fix bugs, minor changes, add Z2. New features are added, but can still be backwards compatible, adding y3. There are great changes that cannot be backwards compatible, adding X NPM has its own test version of the module--node-semver NPM has its own set of modules for verifying version correctness, called Node-semver, which was packaged and installed with NPM in the first. Of course, you can also use it on your own project by installing it yourself. Use an example like this: first NPM install--save Semver then:

Const SEMVER = require (' Semver ') semver.valid (' 1.2.3 ')//' 1.2.3 ' semver.valid (' A.B.C ')//null

Description

Optional field, which must be a string. NPM Search will be used.

Keywords

An optional field, an array of strings. NPM Search will be used.

To put it simply, description and keywords are the search criteria in the NPM search system, so. If you are trying to publish an open source plugin, then these two fields you should pay attention to

Homepage

Optional field, no URL with protocol prefix such as http://.

Bugs

Optional fields, URL or email address of the problem tracking system,NPM bugs .

{"url": "Http://github.com/owner/project/issues",

"Email": "[email protected]"

}

License

An optional field.

If you are using a common license, such as Bsd-3-clause or MIT, use it directly:

{ "license" : "BSD-3-Clause" }

Author, Contributors

are optional fields. Author is a person, contributors is a group of people.

The author format is as follows:

{ "name" : "Barney Rubble",

 "email" : "[email protected]",

 "url" : "http://barnyrubble.tumblr.com/"

}

Name attribute (required) email attribute (optional) URL attribute (optional)

This format can also:

"Barney Rubble <[email protected]> (http://barnyrubble.tumblr.com/)"

Files

An optional field that contains a set of files for the project. If it is a folder, the files under the folder will also be included. If you need to include some files that are not included in the project, add a ". Npmignore" file. This file is similar to "Gitignore".

Main

An optional field. The value of this field is the ID ofYour program's main entry module.

This is the entry file for your project. In short, when when someone installs the module you publish, it is the export (exports) of the module that is returned when require your module. For example, you write {"main": "Xxx.js"}, and someone else installs ' your module name ' via NPM. After installing your module, he is using var X = require (' Your module name ') to get your output in Xxx.jsBin

An optional field. Many packages will have executable files that need to be installed in path.

This field corresponds to a map, and each element corresponds to a {command name: file name}.

{ "bin" : { "npm" : "./cli.js" } }

Directories

The directory structure used to indicate the package:

Directories.lib

Indicates the location of the library file.

Directories.bin

Is the same as the previous bin, but if there is already bin, then this is invalid.

In addition to the above two, there are also directories.doc& Directories.man & Directories.example.

Repository

An optional field. Used to indicate where the code is stored.

"repository" :

  { "type" : "git"

  , "url" : "http://github.com/npm/npm.git"

  }

"repository" :

  { "type" : "svn"

  , "url" : "http://v8.googlecode.com/svn/trunk/"

  }

Scripts

Written into the scripts command, you can run the corresponding shell commands via NPM run <command> or NPM <command>, for example:

{

"Scripts": {"Start": "Node Main.js"}

}

Allows you to enter NPM start at the terminal, which is equivalent to running node main.js

When to add "run", when can not add "run" it? One of the problems that may be troubling to us is that when you run a script from the NPM command in the Script field, sometimes you add "run" and sometimes do not "run", that is, sometimes you can use NPM <command>; and occasionally use NPM run < Command> to run the script, how do you differentiate it? The first thing to mention is that run's original name is Run-script, is a script, and run is its alias (alias) 1. When Run[-script] is used by test, start, restart, and stop, the four self-contained commands It can be omitted (or it can be called directly without "run"), so we usually the most commonly entered NPM start is actually the same as NPM run start, just to make it easier to omit run2. you can't omit "run" when you define a command in the Package.json script field except for the 4 commands in 1 .For example you define

"Scripts": {  "build": "Xxx.js"}

, you can run Xxx.js only by running the NPM run build.

NPM adds the Node_moudles/.bin prefix to the script path in the Scripts field npm adds the Node_moudles/.bin prefix to the script path in the Scripts field, which means: you're trying to run a local installation that relies on Node_ This prefix can be omitted from the Modules/.bin script in the Node_modules/.bin. For example: I just had npm install Webpack, and under my project in the Node_modules directory under the. Bin subdirectory:

There's a script called Webpack.

The command to run this script should be: Node_modules/.bin Webpack But since NPM has automatically added the Node_modules/.bin prefix, we can write it directly:

"Scripts": {"Start": "Webpack"}

Rather than write:

"Scripts": {"Start": "Node_modules/.bin Webpack"}

NPM start has a default value, the default is: node Server.js

·"scripts":{"start": "node server.js"}

If you have a server.js file in your package, NPM will do it by default: node server.js .

·"scripts":{"preinstall":"node-gyp rebuild"}

If there is binding.gyp， NPM in the package, the defaultpreinstall命令时，使用node-gyp做编译。

 

Better-npm-run installation and use of Betterscript fields this is not in the Package.json documentation, but here I would like to say a few words: first install the package via NPM installation Better-npm-run, Then you can use a new field in your Package.json--the "betterscripts" field so that it looks like the "Scripts" field, so what's the connection between the two? Let's talk in code, it can put

"Scripts": {   "test": "Node_env=production Karma Start"}

Become:

"Scripts": {    "test": "Better-npm-run Test"}, "Betterscripts": {"    test": {        "command": "Karma Start",        " Env ": {            " node_env ":" Test "}}       }

Simply put, it is when you run the command in the "Scripts" field that it further runs the corresponding command in "betterscripts" and controls the environment variables at runtime, such as Node_env, through the "Env" object. The advantage is to make your code more readable.Also mention the role of node_env: used to set environment variables (the default value is development). by examining this value, different processing can be done separately for the development environment and the production environment.For example, in the server-side code, check whether the development environment (development) determines whether to start the Code hot reload feature ( Thermal overloading is only intended to increase productivity in the development environment "Developmen", in the production environment "production" hair

if (Process.env.NODE_ENV = = = ' Development ') {//Omit many content App.use (require (' Webpack-hot-middleware ') (compiler, {    path : '/__WEBPACK_HMR '})}

Config

Optional field, object.

The values in the Config object are available throughout the Scripts cycle, specifically to provide configuration parameters for Scripts.

Dependencies

An optional field that indicates the other packages that the current package depends on.

{ "dependencies" :

  { "foo" : "1.0.0 - 2.9999.9999"

  , "bar" : ">=1.0.2 <2.1.2"

  , "baz" : ">1.0.2 <=2.3.4"

  , "boo" : "2.0.1"

  , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"

  , "asd" : "http://asdf.com/asdf.tar.gz"

  , "til" : "~1.2"

  , "elf" : "~1.2.3"

  , "two" : "2.x"

  , "thr" : "3.3.x"

  }

}

The version format can be any one of the following:

• versionExact match
• >versionGreater than this version
• >=versionGreater than or equal to this version
• <version
• <=version
• ~versionVery close to this version
• ^versionCompatible with current version
• 1.2.xX represents any number, so 1.2.1, 1.2.3, etc. can be
• http://...The URL of the tarball used under UNIX systems.
• *Any version is available
• ""Any version is available
• version1 - version2Equivalent to >=version1 <=version2 .
• range1 || range2Meet any one can
• git...git address
• user/repo

Devdependencies

An optional field. If you only need to download and use certain modules without downloading the test and documentation frameworks for those modules, it would be nice to put them under this.

The difference between the Dependencies field and the Devdependencies field dependencies fields and Devdependencies fields represent the production environment dependency and the development environment relies on the NPM install command associated with two fields NPM Install module--save is installed and written to Package.json in dependencies (production environment dependent) NPM Install module--save-dev What is the devdepencies (development environment dependency) that is installed after writing to the Package.json to be placed in dependencies or devdepencies when the package is installed? It's simple. 1. Generally you go to GitHub or the NPM community inside the introduction of the relevant package will be with--save or--save-dev parameters, at this time the command directly copied over the run is OK, do not care so much 2. if there is no 1 in the introduction, then please think, this package is purely for the purpose of the development of easy to use it? Or do you want to put it in the app's code after the launch? The former is devdepencies, while the latter is dependencies"Note": In team collaboration, a common scenario is when someone clones your project from GitHub and then installs the necessary dependencies via NPM install (just clone down from GitHub is no node_modules, Need to install) So what information is installed depending on? Is the dependencies and devdepencies in your Package.json. So, at the same time as the local installation, It is important to write the information of the dependent package (required name and version) into Package.json! Peerdependencies

An optional field. Compatibility dependency. If your package is a plugin, fit this way.

Bundleddependencies

An optional field. Other dependencies that are packaged at the same time as the package is published.

Optionaldependencies

An optional field. If you want to be dependent on some dependencies, even if they are not found, or if the installation fails, NPM continues to execute. Then these dependencies are suitable for putting here.

Engines

An optional field. You can specify either the node version:

{"Engines": {"node": ">=0.10.3 <0.12"}}

You can also specify the NPM version:

{"Engines": {"NPM": "~1.0.20"}}

Enginestrick

Optional field, Boolean value. If you are sure that your program can only be run on the engine that is set to true.

Os

An optional field. Specify what operating system the module can run on:

"OS": ["Darwin", "Linux"]

"OS": ["!win32"]

Cpu

An optional field. Specifies the CPU model.

"CPU": ["x64", "IA32"]

"CPU": ["!arm", "!mips"]

Preferglobal

Optional field, Boolean value. If your package is a command-line application that requires a global installation, it can be set to true.

Private

Optional field, Boolean value. If private is TRUE,NPM, the publication will be rejected. This can prevent private repositories from being released accidentally.

Publishconfig

An optional field. The configuration value to use when publishing is put here.

Package.json of project development