Set npm package to save version with caret (^) - npm

When I $ npm install eslint --savedev, it produces this entry in my package.json file:
"devDependencies": {
"eslint": "^3.9.1"
}
Notice the caret before the version number. When I install a package I've published in the same way $ npm install #jsejcksn/eslint-config --savedev, it does not add the caret:
"devDependencies": {
"#jsejcksn/eslint-config": "0.0.5",
"eslint": "^3.9.1"
}
What do I need to do in order to get npm to save my package with the caret so it will allow major version updates of my package?

From https://docs.npmjs.com/misc/semver#caret-ranges-123-025-004:
Allows changes that do not modify the left-most non-zero digit in the [major, minor, patch] tuple. In other words, this allows patch and minor updates for versions 1.0.0 and above, patch updates for versions 0.X >=0.1.0, and no updates for versions 0.0.X.
I incremented the version to 1.0.0 and it worked as expected.

Related

npm install with major and minor version dependecies

I am trying to create an npm package. Trying to install Lodash with major and minor version dependencies. It should be like minor version 17 and major version 4.
How is it possible?
I have tried
npm install lodash#^4 && ~17 but it seems not what I am expecting. It should me clearly mentioned in package.json as major and minor version dependencies right?
Thanks in advance.
npm install lodash#4.17 will install lodash#4.17.x and update package.json appropriately to require 4.17.x. The entry in package.json could have the format "lodash": "4.17" or something more like "lodash": "^4.17.21", depending on what version of npm you are running.

NPM package.json convert * asterisk to version

I have a package.json from my template with several dependencies.
If I want to create a new project, I use my template.
But how to convert all * (asterisk sign / latest version) to a fixed version which is downloaded from npm. npm install --save does not work.
Before npm install (template package.json)
"devDependencies": {
"one": "*",
"two": "*",
"three": "*"
}
should convert to following by npm i --save.
"devDependencies": {
"one": "1.0.0",
"two": "2.0.0",
"three": "3.0.0"
}
How to overwrite the version string?
As per the documentation
(*) --> Matches any version
("") --> (just an empty string) Same as *
The workaround of this issue is shrinkwrap(Read documentation for further information). You can use this command npm shrinkwrap.That creats a npm-shrinkwrap.json file. When you run the command,You get the following comments on console (npm notice package-lock.json has been renamed to npm-shrinkwrap.json. npm-shrinkwrap.json will be used for future installations.). And that will gave the updated package version whatever you have in package.json.
Use npm list --depth=0 to see what versions were installed by installing 'latest' from your template. You should get something like this:
├── #angular-devkit/architect#0.1501.1
├── #angular-devkit/build-angular#15.1.1
├── #angular-eslint/builder#15.2.0
Copy, modify and paste output into your package.json. Then you should probably remove node_modules and check if running npm ci works properly.
Notes:
This is how you should specify wanted versions in package.json:
"react": "^16.0.0" // carat: allow 16.1.0
"react": "~16.0.0" // tilde: allow 16.0.1
"react": "16.0.0" // exact: only 16.0.0
If your template is fairly complicated, it is highly unlikly that such workflow would be convenient. I would advise having specific versions in the template carefully combined, so that they work. Then, once every couple of months, you should (again, carefully) updgrade libraries in your template. Otherwise, sooner or later you are going to install two latest version of some conflicting pakages.

Should I change all npm packages's distag in package.json to "latest"?

I'm building a boilerplate for my every frontend projects and if I wanted when I run npm install so all my dependencies will be the latest version, Would I change all the packages' distag to "latest" for that purpose?
"#babel/plugin-syntax-dynamic-import": "latest",
"#babel/plugin-transform-runtime": "^7.3.4",
"#babel/preset-env": "^7.3.4",
"babel-eslint": "^10.0.1"
to
"#babel/plugin-syntax-dynamic-import": "latest",
"#babel/plugin-transform-runtime": "latest",
"#babel/preset-env": "latest",
"babel-eslint": "latest"
The package-lock.json
npm v5.2+ comes with a package-lock.json file that is generated when you install packages. This file should be versioned because it contains the information of every package installed.
The idea then becomes that instead of using package.json to resolve and install modules, npm will use the package-lock.json. Because the package-lock specifies a version, location and integrity hash for every module and each of its dependencies, the install it creates will be the same, every single time. It won’t matter what device you are on, or when in the future you install, it should give you the same result every time, which is very useful.
So, if package-lock.json locks down the version of installed packages, what is the problem using "latest"?
The problem lies in that your package.json is not meaningful.
Your package.json does not tell you what version is actually installed, not even a clue.
What if someone overrides the package-lock.json or deletes it.
It is not the end of the world, but having a package.json should give us a clue about the packages we have installed.
Of course you can see a list of your installed packages with versions: npm list --depth=0 and also if you want to update packages, you can see the list of outdated ones: npm outdated
Check out this article: Everything you wanted to know about package-lock.json but were too afraid to ask.
I think it is ok when you use lastest tag as there is no conflict in version of packages.
In the user's guide of distag, they show that:
By default, the latest tag is used by npm to identify the current version of a package, and npm install <pkg> (without any #<version> or #<tag> specifier) installs the latest tag. Typically, projects only use the latest tag for stable release versions, and use other tags for unstable versions such as prereleases.
So if you are gonna to release a stable version, use latest tag will definitely true.

Should I manually update dependencies versions in the package.json after creating a new project with npm?

I've installed this boilerplate with Electron and Vuetify frameworks included: https://github.com/vuetifyjs/electron
Questions:
Should I now manually change those versions in the package.json to the latest and run npm install again?
"dependencies": {
"vue": "^2.4.2",
"vuetify": "0.17.4",
"vue-electron": "^1.0.6",
[...]
},
"devDependencies": {
"electron": "^1.7.5",
[...]
}
Why do those dependencies have that ^ symbol if they still don't download the latest version?
The boilerplate has this code in one of the components and it's displaying the installed versions:
<script>
export default {
data () {
return {
electron: process.versions['atom-shell'],
node: process.versions.node,
vue: require('vue/package.json').version
}
}
}
</script>
It shows that it uses the latest version of vuejs (v2.5.13) but ancient versions of node and electron:
Electron: 1.7.10 even though in the package.json I see "electron": "^1.7.5" while the latest version is 1.8.2. Why is that?
And Node: 7.9.0 which I don't even see it in the package.json. How do I update it to 9.5.0? I suppose, updating Electron will update node automatically, is that how it works?
As far as I worked with npm-packages it is possible to manually change the npm-package version to required but available version. Just after making changes in package.json you can install the dependencies or run npm install and it will install the specified package to project directory.
The tilde(~) sign shows that the rightmost value of specific package version will increment upto the latest available version value that was published. In short, the version ~1.1.2 will match and can update upto all 1.1.X versions of that specific package but will not match or update 1.2.0 version. While ~1.2 will match and can update upto 1.2.* through to 1.X.*.
The caret(^) sign allows you to update package to most recent major version (referencing to the first number of package version). i.e. ^1.1.2 will match any 1.x.x release including 1.2.0, but will not match or update 2.0.0.
Worked for me:
1. npm update vue
If you got error :
vue-template-compiler and vue should be the same version
then run 2 and 3 step
2. npm uninstall vue-template-compiler
3. npm install vue-template-compiler

What exactly does "next" mean in package.json dependencies?

What exactly does next mean in package.json dependencies?
"dependencies": {
"react": "^15.4.2",
"react-dom": "^15.4.2",
"react-router-dom": "next"
}
The next tag is used by some projects to identify the upcoming version.By default, other than latest, no tag has any special significance to npm itself.
NPM Documentation
Specifically, and according to the documentation I found this helpful:
By default, the latest tag is used by npm to identify the current
version of a package, and npm install (without any # or
# specifier) installs the latest tag. Typically, projects only
use the "latest" tag for stable release versions, and use other tags for
unstable versions such as prereleases.
The next tag is used by some projects to identify the upcoming
version.
By default, other than latest, no tag has any special significance to
npm itself.
So, for instance, I had some issues related to npm itself generating npm ERR! Error: EACCES: permission denied errors on package installations, that I first corrected by reverting to an earlier version of npm (from 5.4.0):
npm install -g npm#5.3.0
But npm is also one of those packages that does use the "next" tag in their distribution, so to take advantage of that in the newest but not officially "stable version", you could also run:
npm install -g npm#next
Which installed 5.5.1
Running: npm show npm versions --jsonshows the following version history to give an idea what exactly was installed:
[ ...
"5.3.0",
"5.4.0",
"5.4.1",
"5.4.2",
"5.5.0",
"5.5.1"
]
This answer is an attempt to state the purpose of #next more simply. The language in the docs and in other answers appears overly complex.
Using next as the version number will allow a pre-release version if the project has one available. It will otherwise allow the latest stable version.