NPM install version number ^

npm The dependent version number in is  ^x.y.z, Which versions can be included ？

Today, a colleague has a problem , One of the things we rely on in our code npm package , It's a version of  hard-source-webpack-plugin@^0.12.0, But in execution  npm install  When , The installation is always  0.12.0 This version , Not the latest version of this package  0.13.1 .

At first , I thought it was because of  lock Why , Such as the  package-lock.json  perhaps  yarn.lock, I know someone lock In the document , Locked version for  0.12.0. But the reality is , Because the code of my former colleagues is a little bit bug, Although the source code does have package-lock.json  and  yarn.lock Of documents , But the actual release time , Because of the code bug, These two files were not published to npm In the warehouse .

The current situation is ,package.json The version written in is  ^0.12.0, This bag is in  npm The latest version of the source is  0.13.1. But by npm Install it , Always be 0.12.0 Of , Not at all 0.13.1.

According to the previous understanding , The semantic version is  ^0.12.0, So it can cover  [major, minor, patch]  The three digit version of   The last two   Of , It should be installed automatically 0.13.1 This version .

Is it the pot of cache ？ Um. , There may be ,npm There is indeed a local cache . So clear the local cache  npm cache clean —force, reinstall ,WFT？ still 0.12.0 ah ！！

It doesn't look like the pot of caching . Is that a network problem ？ Neither , Even if you clear the cache, you can still install it to 0.12.0 , The Internet must be OK Of ……

Looks like , Objective cause   It's almost done …… Only from   Subjectively   We got a problem .

Version number  ^0.12.0 , It really includes  0.13.1  Well ？？

Turn it over again  npm Version official document   have a look , Um. , I was wrong before . The document makes it clear that ,^ Specified version range , as long as No modify  [major, minor, patch]  In triples , The first one on the far left is not 0 position , It's all right . in other words , To be sure  ^ The scope of the version , First find   The first one on the far left is not 0 position  , Only the change on the right side of this one , Is included in this  ^  Within the specified range . Take up a ：

• ^1.2.3 The version includes ：>= 1.2.3  also < 2.0.0
• ^0.2.3 The version includes ：>= 0.2.3  also < 0.3.0
• ^0.0.3 The version includes ：>= 0.0.3  also < 0.0.4

meanwhile , I also found one on the official website  npm Command line tools ：semver, Can be installed globally ：npm i -g semver , after , You can use this tool to check what a range version contains , Take today's problems , That's it ：

bogon:~ jess$ semver -r ^0.12.0 0.12.0 0.13.0 0.13.1
0.12.0
bogon:~ jess$
bogon:~ jess$ semver -r ^0.12.0 0.12.0 0.12.1 0.12.10 0.13.0 0.13.1
0.12.0
0.12.1
0.12.10
bogon:~ jess$
bogon:~ jess$

PS ：

We are currently in the application code , To prevent some packages from being upgraded , Not following the semantic version , This leads us to apply after every package , The generated code may be different , Generally used  yarn.lock  perhaps  package-lock.json  To lock the version number of the package the project depends on .

But last time there were students in the open source   Third party package   in , It turns out that most of them are No,  yarn.lock  perhaps  package-lock.json, It's a little strange , Why are these open source packages , Don't lock the dependent third-party version ？

I understand it , It's about these two aspects ：

1. All say nodejs Of  node_modules It's a hole deeper than a black hole , It can be seen that in one of our applications , How many third-party open source packages will you rely on . Every open source package , It depends on a lot of other packages . If every open source package locks its own dependent version , So many of the underlying infrastructure packages , It may be installed many , Although just  patch  There are some version differences , After the front-end code is packaged , The volume will undoubtedly increase a lot . therefore , Open source package for and other open source packages   share   The lower package , You can't lock your own version
2. In fact, the first point has already explained the problem , As the author of open source packages , Maybe there's no other choice , Can only choose Believe in   Other open source package authors , Will strictly abide by   Semantic version   The requirements of

The related documents

• npm Semantic version