According to the document install steps, a week ago it works(install success). When I installed and used the same steps today, and run npm test, it displayed the following error:
enter image description here
I think maybe is Dojo releases update(a day ago), cause something has changed.
Now how can I success to install the intern?
Whether the document install steps need to revise and update?
Thanks.
package.json
"dependencies": {
"tslib": "~1.7.1" }
revise
"dependencies": {
"tslib": "~1.8.0" }
package-lock.json
tslib": "~1.7.1" revise 1.8.0
Related
I'm trying to create a SVG component.
I have this problem after run command "npm i".
I think versions between packages aren't compatible.
How to fix this or create SVG component without react-native-svg package?
Thank a lot.enter image description here
Add the following to package.json:
{
// scripts, dependencies, etc.
"resolutions": {
"css-what": "5.0.1"
},
}
Remove lock file. Install the packages. Check if the app is still working. If works then keep the configuration (and ignore the warnings) else revert it.
Since you are using npm, you may wanna first refer this thread: npm equivalent of yarn resolutions?
I have a ClojureScript project using shadow-cljs. In this project I am using the NPM package #material-ui, which works fine.
Now I would like to use react-swipeable-views. Therefor I have extended my package.json:
"dependencies": {
"#material-ui/core": "^4.5.2",
"#material-ui/icons": "^4.5.1",
"highlight.js": "9.15.10",
"react": "^16.11.0",
"react-dom": "^16.11.0",
"react-flip-move": "3.0.3",
"react-highlight.js": "1.0.7",
"react-swipeable-views": "0.13.3"
}
When I try to require ["react-swipeable-views" :as sv] I get this error from shadow-cljs:
The required JS dependency "dom-helpers/transition/properties" is not
available, it was required by
"node_modules/react-swipeable-views/lib/SwipeableViews.js".
And in fact, there is no transition directory in node_modules/dom-helpers/. But there is import transitionInfo from 'dom-helpers/transition/properties'; in node_modules/react-swipeable-views/src/SwipeableViews.js.
It looks like a dependency bug in react-swipeable-views, but I am a newbie to NPM.
Any suggestions what the problem is? Or how to debug?
UPDATE
It seams react-swipeable-views depends on the outdated dom-helpers#3.4.0 while shadow-cljs uses the current dom-helpers#5.1.3. See https://github.com/oliviertassinari/react-swipeable-views/issues/542
Is it possible to use both? Or will I have to wait until someone fixes react-swipeable-views?
You correctly identified this is caused by a version conflict.
It is not possible to use both versions, you must resolve this version conflict. You can try installing the older dom-helpers version as the default by adding it to your package.json and npm install it. Maybe the library that was using the newer one still works with the old one?
I have npm version 6 installed on my machine. I have the following content in package-lock.json:
{
"name": "Project",
"version": "0.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"package1": {
"version": "0.1.2"
},
"package2": {
"version": "0.2.2"
}
}
}
Whenever I am running npm install it's updating my package-lock.json and new contact is like:
{
"name": "Project",
"version": "0.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"package1": {
"version": "^0.1.2"
},
"package2": {
"version": "~0.2.2"
}
}
}
I am expecting to not add ~ tild or cap ^ into the version of package-lock. I am not even adding or removing any package before npm install. Lock file is very big so it's hard to maintain changes manually.
What is the problem? How should I install new packages without affecting old versions?
As per my understanding and whatever I searched on this,I can able to say that,this(package-lock.json) behavior is refactor to make traceability of dependencies easier, even if getting some large lock file diffs in the meantime is not ideal.
package-lock.json should be the tool and mechanism what is responsible to keep everything consistent, so the trust in it is unavoidable and necessary.
Documentation
package-lock.json describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
For example, package.json is:
...
"glamor": "^2.10.00"
...
In package-lock, there are links to specific versions, for example, https://registry.npmjs.org/glamor /-/glamor-2.20.40.tgz
The change only touched the format of the require description.
It was:
"requires": {
"glamor": "2.20.40"
}
Became:
"requires": {
"glamor": "^2.0.0"
}
Semver was not broken (2.20.40 is still matching to ^2.0.0), and the links remained in place
When the package version is updated, the package will still be taken from the link file (there is an old version of the package)
To update the link in the lock file, you must either change package.json or make npm update. For more reference npm issues
More explanation on this:
Let's say that you use pinned versions of dependencies 'aaa', 'bbb' and 'ccc'. Let's say they each depend on 'zzz' like so:
aaa depends on zzz#^1.0.0
bbb depends on zzz#^1.1.0
ccc depends on zzz#^1.0.1
i.e. all three of them depend on a range of zzz, and not an exact version.
And let's say that the latest version of zzz is 1.5.0.
Both before and after this change, it's pretty obvious that the resolved version of zzz should be 1.5.0, so the only difference is how the package-lock.json is structured and documents this sub-dependency.
Before, the lock file would show that all three of them depend on zzz#1.5.0, and the resolved version of z is 1.5.0.
Now, it documents the actual "original" dependency versions (e.g. ^1.0.0, ^1.1.0, etc) for each dependency, but still shows the resolved version of z as 1.5.0.
Then consider what happens when zzz#1.5.1 is released:
Before, the lock file would need to update from z#1.5.0 to z#1.5.1 in all four places.
Now, the lock file only needs to update the resolved version of z to 1.5.1 while the dependencies can keep the ^1.0.0, ^1.1.0, and ^1.0.1 because they haven't changed.
As I mentioned previously in the thread, you still get the exact same node_modules in both cases. The advantages of the new approach are:
You get to see what the dependencies actually require (e.g. a range, and not an exact version). before, you could not tell if aaa actually required exactly zzz#1.5.0 or that it was instead zzz#^1.0.0.
Instead of four lines changing in the lock file, you get only one. It's less churn, and it's more clear what's happened.
As an aside, yarn uses a similar concept with yarn.lock. e.g. here's an example where #sindresorhus/is is pinned, but it's sub-dependency symbol-observable is not:
"#sindresorhus/is#0.10.0":
version "0.10.0"
resolved "https://registry.yarnpkg.com/#sindresorhus/is/-/is-0.10.0.tgz#f42dd6a9d12cd79fa6f53b27cf5bea3a30d2cafa"
dependencies:
symbol-observable "^1.2.0"
npm is causing me grief and I have no idea why. Trying to publish a new version of my package.
npm view {{package}} versions
[ '0.3.0',
'0.3.1',
'0.4.0',
'0.4.2',
'0.5.0',
'0.6.0',
'0.6.1',
'0.7.0',
'0.7.1',
'0.8.0',
'0.8.1',
'0.8.2',
'0.8.3',
'0.8.4',
'0.8.5' ]
When I run npm publish I get this:
400 Bad Request - PUT https://registry.npmjs.org/{{package}} - Cannot publish over previously published version "1.0.0".
This is my current package.json:
...
"version": "1.0.0",
...
What gives?
EDIT:
Further, even when I try to patch the version and publish a 1.0.1 or a 1.0.2 I get the same message....good grief...
So when I was first creating my package a few months ago, I had originally published a 1.0, decided I didn't like it and unpublished it from the registry. I had forgotten I had done this and, due to NPMs policies, which I support, they don't allow you to republish a version of a package that had previously been published. Had to version bump to 1.0.3 in order to get it to work. Might help somebody else out.
EDIT: The npm view command (with the --json flag) can give you some insight into what's happened. It'll output something like this close to the top
"time": {
"created": "2020-06-09T19:57:19.446Z",
"1.0.0": "2020-06-09T19:57:19.720Z",
"modified": "2020-08-23T21:31:17.255Z",
"1.0.1": "2020-06-09T23:32:53.322Z",
"2.0.0": "2020-06-10T12:49:09.722Z",
"2.0.1": "2020-06-10T13:17:40.021Z",
"2.0.2": "2020-06-10T19:37:09.994Z",
"2.0.3": "2020-06-11T00:24:46.982Z",
"2.0.4": "2020-08-20T21:18:46.305Z",
"2.0.5": "2020-08-20T21:20:42.971Z",
"2.0.6": "2020-08-20T21:35:22.181Z",
"2.0.7": "2020-08-20T22:30:24.183Z",
"2.0.8": "2020-08-20T22:42:05.255Z",
"2.0.9": "2020-08-23T21:31:15.021Z"
},
You cannot publish a package at the version it was unpublished before. You can read more about npm's policy here.
https://www.npmjs.com/policies/unpublish
Anyone knows a trick to install multiple versions of the same package through npmjs ? I know it's not possible to use the same package-name in package.json but it gives you an idea of what I try to achieve:
"dependencies": {
"mypackage": "user/mypackage#v1.0",
"mypackage": "user/mypackage#v2.0"
}
At the end, I want to A/B test my package with different versions. Thanks a lot !
Based on npm discussion, this won't be implemented any time soon.
Some reference:
https://github.com/npm/npm/issues/5499
https://github.com/npm/npm/issues/2943