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.
Related
I have created my own npm feed in Azure Artifacts. I can publish my package and use it in my applications.
In my applications, the package is referenced like this in the package.json
`"#op/breeze-helpers": "^0.1.5"`
If I now publish version 0.1.6 of my package, delete my package from node_modules and run npm i , npm installs version 0.1.5 again !
I even tried npm i --cache c:/tmp/empty-cache to make sure it was not getting the package from cache, but it ends up the same. npm keeps installing version 0.1.5
what am doing wrong, I thought with the caret, the next minor should be downloaded when running npm i ?
The package-lock.json sets your currently installed version of each package in stone, and npm will use those exact versions when running npm install.
So it will download the package versions from the package-lock.json file.
I want to be on latest version always.
You could try to set the "*" as the dependency package version.
For example:
"dependencies": {
"#types/bootstrap": "*",
"#types/jquery": "*",
"bootstrap": "*"
}
Then it will always download the latest version of the target packages.
When and how can we upgrade the dependencies that create-react-app adds to package.json?
Today I ran npx create-react-app my-app --template typescript and it added these dependencies:
"dependencies": {
"#testing-library/jest-dom": "^4.2.4",
"#testing-library/react": "^9.3.2",
"#testing-library/user-event": "^7.1.2",
"#types/jest": "^24.0.0",
"#types/node": "^12.0.0",
"#types/react": "^16.9.0",
"#types/react-dom": "^16.9.0",
"react": "^16.13.1",
"react-dom": "^16.13.1",
"react-scripts": "3.4.3",
"typescript": "~3.7.2"
}
Even though some have newer versions available:
"#testing-library/jest-dom": "^5.11.4"
"#testing-library/react": "^11.0.4"
"#testing-library/user-event": "^12.1.6"
"typescript": "~4.0.3"
Can we upgrade any dependency at any time or are they tied to the specific version of react-scripts? If it is the latter how do we know when to upgrade and what version to upgrade to?
When?
I'm still figuring that out, but maybe when a dependency (e.g. #testing-library/user-event) strongly recommends updating.
and how
Here is a walkthrough of how to update dependencies. Your mileage may vary. I recommend testing each change before moving to the next. Some dependencies may need to go together.
I recently (2022) ran npx create-react-app my-app --template typescript and analyzing the dependencies with npm outdated for me shows:
Package Current Wanted Latest
#testing-library/user-event 13.5.0 13.5.0 14.4.3
#types/jest 28.1.8 28.1.8 29.1.2
#types/node 18.7.14 18.8.3 18.8.3
web-vitals 2.1.4 2.1.4 3.0.3
Major version upgrades:
You can see that #testing-library/user-event does not "want" a higher version, but a higher MAJOR version does exist.
In order to upgrade major versions, which in theory does not happen as frequently as minor versions, I use a brute force method which involves npm uninstall <package-name> and then npm install <package-name>.
For package #testing-library/user-event,
# show the version installed
npm list | grep '#testing-library/user-event'
npm uninstall -D #testing-library/user-event
npm list | grep '#testing-library/user-event'
npm uninstall -D #testing-library/user-event
npm list | grep '#testing-library/user-event'
The following is printed for the above commands
├── #testing-library/user-event#13.5.0
├── #testing-library/user-event#14.4.3
Executing npm outdated again shows #testing-library/user-event is omitted. Success!
Package Current Wanted Latest
#types/jest 28.1.8 28.1.8 29.1.2
#types/node 18.7.14 18.8.3 18.8.3
web-vitals 2.1.4 2.1.4 3.0.3
Minor version upgrades:
Updating a package to a higher minor version can be accomplished using npm update.
You can see that #types/node has a higher MINOR version available that npm outdated marks as Wanted. You can upgrade any single package wanting a MINOR upgrade by saying npm update <package-name>, or ALL packages wanting a minor upgrade by omitting the package name, e.g. npm update
For upgrading only package #types/node,
npm update #types/node
npm outdated
Running the commands above show #types/node is no longer "Wanted" to upgrade, visible in the following output. Success!
Package Current Wanted Latest
#types/jest 28.1.8 28.1.8 29.1.2
web-vitals 2.1.4 2.1.4 3.0.3
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.
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.
I'm getting the following error from a few different libraries in my project, after adding the "stage-2" preset to my .babelrc. (Thats my assumption atm)
e.g. from the DatePicker class in React Native:
node_modules/react-native/Libraries/Components/DatePickerAndroid/DatePickerAndroid.android.js: You gave us a visitor for the node type "ForAwaitStatement" but it's not a valid type
How can I resolve this error?
I'm using React Native 0.31 and
"devDependencies": {
"babel-preset-react-native-stage-0": "^1.0.1",
"babel-preset-stage-2": "^6.17.0"
},
I too ran into this. Solved by updating my babel-core version by changing the entry in package.json to the latest (at the time of this writing)
// package.json
...
"babel-core": "6.17.0",
...
then running
rm -r node_modules/babel* && npm i
I had the same issue after updating babel-core and some babel plugins. In my case it was fixed by updating babel-cli (globally installed with npm), which was a few versions behind and not using the right babel-core version.
I encountered this after an npm update, struggled for several hours to find a fix, but ultimately solved it via rm -rf node_modules && npm install. I hate npm.
I found this issue is caused by a lower version babel-types, so the solution is just:
npm install babel-types
or a clean npm install:
git clean -fdx
npm install
If your babel-cli is out of date, you might get the same error. Try updateing babel-cli using npm install babel-cli -g or update your local babel-cli and reference it in your package.json scripts.
Also do npm i -D babel-plugin-transform-runtime and add "plugins": ["transform-runtime"] to your .babelrc
Had a similar situation as #Thomas; a globally installed version of babel-cli which was behind. I can recommend not installing it globally, instead running babel through npm scripts.
Local install:
npm install babel-cli --save-dev
In your npm scripts:
"babel": "babel script.js"