webpack-cli
webpack-cli copied to clipboard
[BUG]: webpack does not find globally installed @webpack-cli/init by Yarn
Describe the bug
webpack-cli
says that it needs the @webpack-cli/init
even when I have done yarn global add @webpack-cli/init
What is the current behavior?
It seems webpack-cli
does not find @webpack-cli/init
when it was globally installed with Yarn.
To Reproduce Steps to reproduce the behavior:
-
yarn global add webpack-cli @webpack-cli/init
-
webpack-cli init
But doing npm i -g @webpack-cli init
by webpack-cli
also completely fails now on Windows but the issue is also happening on Ubuntu 18.
The command moved into a separate package: @webpack-cli/init
Would you like to install init? (That will run npm install -g @webpack-cli/init) (yes/NO) : yes
npm WARN deprecated [email protected]: use String.prototype.padStart()
npm WARN rollback Rolling back [email protected] failed (this is probably harmless): EPERM: operation not permitted, lstat 'C:\Users\Daniel\scoop\apps\nvm\current\nodejs\nodejs\node_modules\@webpack-cli\init\node_modules\fsevents\node_modules'
npm WARN [email protected] requires a peer of acorn@^6.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\@webpack-cli\init\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
+ @webpack-cli/[email protected]
updated 1 package in 56.613s
Error: spawn npm ENOENT
at Process.ChildProcess._handle.onexit (internal/child_process.js:264:19)
at onErrorNT (internal/child_process.js:456:16)
at processTicksAndRejections (internal/process/task_queues.js:84:9) {
errno: 'ENOENT',
code: 'ENOENT',
syscall: 'spawn npm',
path: 'npm',
spawnargs: [ 'root', '-g' ]
}
Expected behavior
webpack-cli
should not ask to install it using npm
.
Please paste the results of webpack-cli info
here, and mention other relevant information
System:
OS: Windows 10
CPU: (8) x64 Intel(R) Core(TM) i7-4702MQ CPU @ 2.20GHz
Binaries:
Node: 12.4.0 - ~\scoop\apps\nvm\current\nodejs\nodejs\node.EXE
Yarn: 1.13.0 - ~\scoop\apps\yarn\current\Yarn\bin\yarn.CMD
npm: 6.9.0 - ~\scoop\apps\nvm\current\nodejs\nodejs\npm.CMD
Additional context Yarn installed through scoop on Windows 10. node installed through nvm for Windows.
Gotta something to do with this 👇
[email protected] (node_modules@webpack-cli\init\node_modules\fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
it's stopping the new package installation in windows.
ALso
Installing globally with yarn
is not adding the package in the global path,
I installed using npm
Atleast in my machine I guess - window 10
Hi @anikethsaha,
No, this is just something additional which happens only with npm (see the last few lines). Also it is just a warning. See the returned error object.
When I do yarn global add @webpack-cli/init
it installs it but webpack-cli init
says it still wants to install it.
Installing globally with yarn is not adding the package in the global path, I installed using npm
This should not be the case, it should work with any client. Also with Yarn.
The info and init packages do not define any binary name which is fine. They are added to the global scope as normal packages. npm_execpath
is maybe an option but why not also check if the user uses yarn or npm by checking process.argv[0]
?
When I do yarn global add @webpack-cli/init it installs it but webpack-cli init says it still wants to install it.
In my machine, the yarn is not actually adding the @webpack-cli/init
in the global dir. That's why I am getting that error. When I am adding it manually it's working.
Also wired dates coming when installing using npm, you can see the node_modules
folder and package.json
are having the correct date but not the others.
Not sure whether something is wrong in my machine or with npm 😁
In my machine, the yarn is not actually adding the
@webpack-cli/init
in the global dir.
Maybe we need preferGlobal
in https://github.com/webpack/webpack-cli/blob/master/packages/init/package.json
But npm has a different opinion about binaries, see https://docs.npmjs.com/files/package.json#preferglobal
This option used to trigger an npm warning, but it will no longer warn. It is purely there for informational purposes. It is now recommended that you install any binaries as local devDependencies wherever possible.
Also wired dates coming when installing using npm
This is normal and a workaround by npm. I would have chosen another.
https://github.com/npm/cli/search?q=1985&unscoped_q=1985
https://github.com/npm/cli/blob/36682d4482cddee0acc55e8d75b3bee6e78fff37/lib/pack.js#L146-L148
// Provide a specific date in the 1980s for the benefit of zip,
// which is confounded by files dated at the Unix epoch 0.
mtime: new Date('1985-10-26T08:15:00.000Z'),
https://github.com/npm/cli/commit/58d2aa58d5f9c4db49f57a5f33952b3106778669 https://github.com/npm/npm/pull/20027#discussion_r173985677 https://github.com/npm/npm/issues/20439#issuecomment-385121133 https://github.com/npm/npm/issues/19933 https://github.com/npm/npm/issues/19968
Yarn does not need this weird trick because they compare contents, not dates (dates can be always faked / wrong).
So maybe Yarn and a global installation only with Yarn is not supported and we have to use npm?
So what can be done here to fix it ! may be to convert it into binary ?
@DanielRuf @evenstensberg
Just doing npm seems reasonable to me
@evenstensberg @DanielRuf @anikethsaha I am getting the following error on reciprocating -
/usr/lib/node_modules/@webpack-cli/init/node_modules/@webpack-cli/utils/npm-packages-exists.js:42
throw new TypeError(chalk_1.default.bold(`${scaffold} isn't a valid name.\n`) +
^
TypeError: init isn't a valid name.
It should be prefixed with 'webpack-scaffold', but have different suffix.
at /usr/lib/node_modules/@webpack-cli/init/node_modules/@webpack-cli/utils/npm-packages-exists.js:42:19
at Array.forEach (<anonymous>)
at Object.npmPackagesExists [as default] (/usr/lib/node_modules/@webpack-cli/init/node_modules/@webpack-cli/utils/npm-packages-exists.js:26:9)
at initializeInquirer (/usr/lib/node_modules/@webpack-cli/init/index.js:23:41)
at runWhenInstalled (/usr/local/share/.config/yarn/global/node_modules/webpack-cli/bin/utils/prompt-command.js:46:9)
at promptForInstallation (/usr/local/share/.config/yarn/global/node_modules/webpack-cli/bin/utils/prompt-command.js:140:10)
at /usr/local/share/.config/yarn/global/node_modules/webpack-cli/bin/cli.js:32:43
at Object.<anonymous> (/usr/local/share/.config/yarn/global/node_modules/webpack-cli/bin/cli.js:366:3)
at Module._compile (internal/modules/cjs/loader.js:959:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:995:10)
Refer following comment for this. https://github.com/webpack/webpack-cli/issues/1127#issuecomment-561169959
This issue had no activity for at least half a year.
It's subject to automatic issue closing if there is no activity in the next 15 days.
Bump, we need test it for v4
This issue had no activity for at least half a year.
It's subject to automatic issue closing if there is no activity in the next 15 days.
bump
This issue had no activity for at least half a year.
It's subject to automatic issue closing if there is no activity in the next 15 days.
Bump
This issue had no activity for at least half a year.
It's subject to automatic issue closing if there is no activity in the next 15 days.
Issue was closed because of inactivity.
If you think this is still a valid issue, please file a new issue with additional information.