Yarn

[Eric Clemmons]

It's awesome. Let's support it.

I wish I could rename to auto-install-webpack-plugin, but it's taken & competitive.

I mean, I could do yarn-install-webpack-plugin (alias?), but that seems extreme.

What'd also make it legit would be to auto-install yarn if that's how deps would be managed. 😱

I just don't know what to call the option...

new NpmInstallWebpackPlugin({
  ["client" || "installer" || "script" || "exec" || "bin"]: "yarn add",
  ...
});

I would like to opt for something like yarn: true for restricting the API, so that I don't have to support possible script combination (e.g. $PATH=~/.bin pnpm install --save-dev or something)...

[Christoph Werner]

This is what keeps me from using it on non-lib projects atm.

Can i help? I think a boolean flag would be totally sufficient and a first take on it could require a globally installed yarn to work.

[Jan Nicklas]

You could also create a very thin yarn-install-webpack-plugin which would have only the npm-install-webpack-plugin and yarn as dependency

[Steven Hargrove]

Was curious on the status of this, as I'd like to use it.

[Eric Clemmons]

I'll grant contributor rights to anyone who submits a PR. :)

What do you guys think of pivoting off of yarn.lock automatically?

[Zeno Jiricek]

Your install method does too much imo.
https://github.com/webpack-contrib/npm-install-webpack-plugin/blob/master/src/installer.js#L123

but anyway, you should make the method overridable:

new NpmInstallWebpackPlugin({
  ..
  install (missingModules) {
    return new Promise((resolve, reject) => {
     fs.spawnExec('yarn', ['add', ...missingModules, '--dev'], (err) => {
        if (err){ reject(err); }
        else { resolve(); }
     });
    });
  }
  ...
});