"NPM," man, give me a glass of package.json!. No sugar __js

The difference between a directory json and a JS object the Limit version field of the Name Field Name field NPM's rules for version definitions require NPM to have its own module for validation version--node-semver  Keywords and description field field requirements: License Field Author field main Field the Script field when to add "run", when you can not add "run". NPM adds the Node_moudles/.bin prefix to the script path in the Scripts field NPM start has a default value, the default is: node Server.js better-npm-run installation and Betterscript field usage Dependencies field and devdependencies field how to distinguish between the end of the installation package in the dependencies or devdepencies.

Body

foreword: Late at night, I boil a pot of steaming package.json, give everybody end up, hope everybody likesBack to the top of JSON and JS object difference Package.json, as the name suggests, it is a JSON file, and can not write JS object. So the first thing we have to understand is the difference between JSON and JS objects: (Source: Found are crawled by the article, it can not find the original author. If someone knows the original author to me add a name of the original author Ah ~ "Note" in the JSON property name must be added double quotes back to the top Name field the Limit 1.name field for the Name field must be less than 214 characters (this is nothing to remember ~) 2.name fields cannot contain "." Symbols and underscores ( this to remember Oh ~) 3.name fields cannot contain uppercase letters ( this to remember Oh ~) 4.name fields cannot contain non-URL-safe characters because it will be published when It will be written to the URL as the relevant information for your package, so what are the characters that are not URL-safe? Let's look at the table and talk: (Figure Source: Reserved and unsafe characters in URLs--tianya23) "Note": 1. The only thing I feel special to note is that the Name field cannot contain uppercase letters and underscores, because the habit of the hump nomenclature tends to try to add a capital letter to the person who writes JS.   And for those of you who write node, you may be tempted to underline the word and the word, which is the source of the error. The 2.package.json name field seems to be particularly fond of the "-" symbol, so we can use it as a connection symbol when we write the name field, for example: Return to the top of the field like "React-router" version Field NPM's rules for version definition require for "version": "x.y.z" 1. Fix bugs, minor changes, add Z 2. Added new features, but still backward compatible, increase Y 3. There are great changes that cannot be backwards compatible, increase X For example: My original project is 1.0.0 Version If 1 of the situation, into 1.0.1 if 2 of the situation, into 1.1.0 if 3 of the situation, into 2.0.0 NPM has its own version of the module--node-semver NPM has its own set of modules to verify version correctness, called Node-semver, which was packaged and installed with NPM in the first. Of course, you can also use it in your own project by installing it yourself. Use examples 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

"Spit": How does it feel like there is no big use, but the official document on this I have to translate it. Detailed information turn left: Https://github.com/npm/node-semver the Name field and the version field can be said to be the most important and basic two fields of Package.json. Together they make up the unique identity of your package back to the top keywords and description field Requirements: Description: Strings Keywords: string array Simply put, these two things are search conditions in the NPM search system, so. If you are trying to post an open source plugin, then these two fields you should attach to the top license Field This is the license for the project you specify and it tells others whether they have the right to use your package as well, What restrictions should they be subjected to when using your bag let 's go to the last picture:

Figure Source: How to choose an open source license. "--Ruan one peak field requirement: Single License: Write name directly

{"License": "Bsd-3-clause"}

Multiple License: Writes a license name within a pair of parentheses and joins within multiple license with and

{"License": "(ISC and GPL-3.0)"}

Syntax rules for more license fields please turn right: SPDX license expression Syntax Rule version 2.0 HTTPS://WWW.NPMJS.COM/PACKAGE/SPDX back to the top Author Field requirements: A string or an object. If it is an object, the object contains three properties: the name attribute (required) email attribute (optional) URL property (optional)

{"Name": "Barney Rubble"
, "email": "b@rubble.com"
, "url": "http://barnyrubble.tumblr.com/"
}

back to the top of Main field This is the entry file for your project. In short, when someone installs your module, require your module with the output of the entry file specified in your main field. For example, you write {"main": "Xxx.js"}, and others pass NPM install ' your module name '. After installing your module, he obtains from the var X = require (' Your module name ') The output you have in the Xxx.js /c10> back to the top ofThe script field is written into the scripts command, and you can run the corresponding shell directive through NPM run <command> or NPM <command>, for example: { Scripts ": {" Start ":" Node Main.js "}} allows you to run the node Main.js when the terminal enters NPM startWhen to add "run", when you can not add "run". One of the things that might be bothering us is that when you run a script from the NPM command in the Script field, you sometimes add "run" and sometimes you don't add "run", which means that you can use NPM <command>; sometimes and then use NPM run   <command> to run the script, how can this be distinguished? The first thing to mention is that the name of Run is Run-script, a script, and run is one of its aliases (alias) 1. When Run[-script] is used by the four self-contained commands of test, start, restart, and stop, It can be omitted (or can be called without "run"), so the NPM install that we usually enter is actually the same as the npm run install, just to make it easy to omit run. Original: Run[-script] is used by the test, start, restart, and stop commands, but can be called directly 2. when you define a command in Package.json's script field except for the 4 commands in 1, you can't omit "run" for example, you define

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

, you run the xxx.js and run it through the NPM run build. NPM adds the node_moudles/.bin prefix to the script path in the Scripts field . NPM adds a node_moudles/.bin prefix to the script path in the Scripts field. This means that you can omit the node_modules/.bin prefix when you try to run a locally installed script that relies on node_modules/.bin. For example: I just npm install Webpack, and in my project under the Node_modules directory of the. Bin subdirectory:

There's one more 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 for us, we can write it directly:

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

Without having to write:

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

Original: NPM run adds Node_modules/.bin to the PATH provided to scripts. Any binaries provided by locally-installed dependencies can be used without the Node_modules/.bin prefix NPM Start has a default value, and the default is: node Server.js back to top installation of Better-npm-run and use of betterscript fieldsThis is not in the Package.json documentation, but here I would like to say a few words: first install the package through NPM install Better-npm-run, and then you can use a new field in your Package.json--" betterscripts "Field name thinking, it and" Scripts "field is very similar, then what is the relationship 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, when you run the command in the "Scripts" field, it goes further to run the corresponding command in "betterscripts" and controls the Run-time environment variables, such as node_env, through the "Env" object.The good thing is to make your code more readable .Also mention the role of node_env:use to set environment variables (the default is development). by checking this value, you can do different processing for the development environment and the production environment separately.For example, in the server-side code, by checking whether the development environment (development) determines whether to start the Code thermal overload feature (Thermal overload is only in the development environment "developmen" to improve production efficiency, in the production environment "production" no hair use)

if (Process.env.NODE_ENV = = ' development ') {
//omit
a lot of content app.use (require (' Webpack-hot-middleware ') (Compiler, {
    path: '/__WEBPACK_HMR '
})
}

Back to the top of dependencies fields and devdependencies fields dependencies fields and Devdependencies fields represent the production environment dependencies and the development environment relies on two-field NPM Install's command NPM Install module--save is installed and written to Package.json dependencies (production environment dependent) NPM Install module--save-dev After installation, write to Package.json devdepencies (development environment dependent) How do you distinguish between installing a package in a dependencies or a devdepencies? very simple 1. Generally you go to GitHub or NPM community inside the introduction of the package will have--save or--save-dev parameters, this time the command directly copied over the run on the OK, do not care so much   2. If there is no introduction in 1, consider whether the package is purely for the sake of development and convenience. Or should you put it in the code after the app. The former is devdepencies, while the latter is dependencies   "attention": in teamwork, a common scenario is for others to clone your project from GitHub, then install the necessary dependencies through NPM install, (Just from the GitHub clone down is not node_modules, need to install) so according to what information installation depends on it. Is the dependencies and devdepencies in your Package.json. Therefore, it is important to write the information about the package (the required name and version) to the Package.json, while it is installed locally.   Reference: NPM official documentation Packagejson configuration  https://docs.npmjs.com/files/package.json  

  Quietly asked React,redux beauty, redux~ beauty ~ not beautiful ~