Any version from v1.5.1 to 1.7.0beta.0 returns this msg on the clean installations:
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/@angular/cli/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN @schematics/[email protected] requires a peer of @angular-devkit/[email protected] but none was installed.
npm WARN @angular-devkit/[email protected] requires a peer of @angular-devkit/[email protected] but none was installed.
v1.5.1 until v1.7.0.beta.0 and linuxmint 17.3 & lubuntu 17.10
npm returns this warning at end
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/@angular/cli/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN @schematics/[email protected] requires a peer of @angular-devkit/[email protected] but none was installed.
npm WARN @angular-devkit/[email protected] requires a peer of @angular-devkit/[email protected] but none was installed.
After the installation, ng -v returns this error
Error: Cannot find module '@angular-devkit/core'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/usr/lib/node_modules/@angular/cli/node_modules/@angular-devkit/schematics/src/tree/virtual.js:10:16)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3
We are encountering the same issue after the dependency changes. This started with commit cd4eb34177e3f47753cec02cccae4617452f67e8
The issue temporarily went away for us with the rollback to the changes in the devkit today. But with the latest patch update the build error returned.
For those trying to get around this temporarily until a fix comes out:
npm i --no-save @angular-devkit/[email protected]
I can also confirm that running _npm i --no-save @angular-devkit/[email protected]_ worked for me as well.
But my cli version is 1.5.0!!
"@angular/cli": "1.5.0",
I encountered this problem on 1.6.3 and 1.6.4.
Updated to 1.6.5 and on a fresh install this problem doesn't occur anymore. If anyone could confirm.
@angular-devkit/core seems to migrate from depeendency in @angular-devkit/schematics version 0.0.39 to peerdependency in version 0.0.51. as a result its not installed with a clean install anymore
as @aangular/cli depends upon schematics and not corefor version^1.5.0`
"dependencies": {
"@angular-devkit/build-optimizer": "~0.0.31",
"@angular-devkit/schematics": "~0.0.34",
in this commit, so between versions 0.0.48 and 0.0.49 i think
edit: ok, is there something one can do with:
npm shrinkwrap
to lock ALL versions?
If yes, why this not the default?..
ok, I'm sorry. Does it all mean that if I reference the angular/cli dependency with no prefix with a fix version which then work on the day. Something like this:
We are encountering the same issue after the dependency changes. This started with commit cd4eb34
The issue temporarily went away for us with the rollback to the changes in the devkit today. But with the latest patch update the build error returned.
Can still happen, because you use the tilde(~)-prefix in your dependencies?
So one day the whole process runs and one day not any more?
How is this reliable in a CI environment?
Why it doesn't work like Maven & co?
I'm sorry, but the whole npm stuff is broken by design.. a really unmistakeable sh*thole.. :(
Yesterday we put out several releases for minor version that should address this: 1.4.10, 1.5.6, 1.6.5 and 1.7.0-beta.1. We also locked down the devkit dependencies on 1.4.10 and 1.5.6 so this does not happen again if you choose to stay on older versions.
Updating to the latest version within the minor you're using should fix this issue. For example, if you are on 1.5.1, updating to 1.5.6 should fix it.
I'd also like to remind everyone that unless you use a lockfile you do not have reproducible installs. Both NPM v5+ and Yarn support lockfiles. If your CI works one day but not the next and you did not change your code or package.json, it is likely because one of your dependencies had a bad release and you did not have a lockfile.
It is your responsibility as a library consumer to use lockfiles. No one wants to do a release with bugs but it sometimes happens, and the best we can do is to fix it as fast as possible with a new release. When you have a couple of thousand total dependencies it is only a matter of time until one of them has a bad release.
@filipesilva you make a very good point above, however I was under the impression that this is happening based on the globally installed version of @angular/cli - I might be wrong but I wasn't aware of there being a global lock file of the type used by yarn or the more recent versions of npm.
Is there anything you can suggest to mitigate based on this?
In my own case this seems to have started when I changed machine (I don't have the chance to go back to the previous machine to check for the time being), even though the project itself has the yarn lock file so would have downloaded the given specific versions.
I fixed this in my project by doing the following: npm i -g @angular/cli (currently upgrades to 1.6.6)
Creating a completely new project elsewhere in my file system using ng new xxx. I also added @angular/material, @angular/cdk and hammerjs to that project just make sure they all play nicely (which they did).
Copied the relevant package.json dependencies into my current project, wiped node_modules and did yarn install (npm install for the yarnless).
Ran ng g c test -dr to check this was OK - everything is back to normal now
@blackholegalaxy - I can confirm that your solution works on a brand-spanking-new project. Thanks for saving me a headache.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
Yesterday we put out several releases for minor version that should address this:
1.4.10,1.5.6,1.6.5and1.7.0-beta.1. We also locked down the devkit dependencies on1.4.10and1.5.6so this does not happen again if you choose to stay on older versions.Updating to the latest version within the minor you're using should fix this issue. For example, if you are on
1.5.1, updating to1.5.6should fix it.I'd also like to remind everyone that unless you use a lockfile you do not have reproducible installs. Both NPM v5+ and Yarn support lockfiles. If your CI works one day but not the next and you did not change your code or
package.json, it is likely because one of your dependencies had a bad release and you did not have a lockfile.It is your responsibility as a library consumer to use lockfiles. No one wants to do a release with bugs but it sometimes happens, and the best we can do is to fix it as fast as possible with a new release. When you have a couple of thousand total dependencies it is only a matter of time until one of them has a bad release.