Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why does this hijack my default webpack bin? #1281

Closed
csergiu opened this issue Feb 19, 2018 · 4 comments
Closed

Why does this hijack my default webpack bin? #1281

csergiu opened this issue Feb 19, 2018 · 4 comments

Comments

@csergiu
Copy link

csergiu commented Feb 19, 2018

It's NOT okay to hijack my default webpack command, I have other projects where I'm either not using RoR or they don't use webpacker, and it keeps asking for the config:

Webpack config /Users/csergiu/[...]/config/webpack/development.js not found, please run 'bundle exec rails webpacker:install' to install webpacker with default configs or add the missing config file for your custom environment.

How do I uninstall this? I don't want to run node ./node_modules/webpack/bin/webpack.js everytime. Thanks.

@gauravtiwari
Copy link
Member

Thanks @csergiu for pointing out. Seems like we accidentally added binstubs as gem executables, will push a PR to fix this. In meantime, you could uninstall the gem - gem uninstall webpacker, which will remove executables from path.

@rossta
Copy link
Member

rossta commented Feb 21, 2018

@gauravtiwari The binstubs are gem executables because that's what was needed to make install work through bundle binstubs. A few potential solutions I could tackle here:

  1. Rename the gem's executables so they don't override the npm package, e.g. webpack, webpack-dev-server => webpacker, webpacker-dev-server. We'd keep the convenience of bundle binstubs but also potentially break existing scripts that depend on bin/webpack (or provide some symlinks as a mitigating step).
  2. Update the executables so they work with bundler, manually copy them during the install step, and remove them from the gemspec so they don't get added to $PATH. We'd no longer be able to use bundle binstubs but I'd expect the executables not to change often/ever.

Thoughts?

@matthewd
Copy link
Member

@rossta I think number two is the way to go; by keeping the class extraction from #833, I agree the generated scripts should ~never need to change.

@gauravtiwari
Copy link
Member

Thanks @rossta 🍰

As @matthewd pointed out number 2 makes more sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants