-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Option to install or export default webpack config from @rails/webpacker? #794
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
Comments
You can require config directly (but perhaps a named export from @rails/webpacker would be more robust):
And on plugins, have a look at webpack-merge, for example this would replace the default Uglify with latest:
Alteratively, you could move the webpack-merging for each env to your own webpack config folder, and import the defaults from |
If I'm not mistaken this still relies on the remote package. I'd like to have full control in my local project so I know what's being used where (and easily modified). Is Looks like all the necessary files are included with the gem, so this would be pretty easy. |
#884 is now merged - please see PR for docs |
#884 solves the order issue, very helpful. I still feel that adding an API around webpack config is an over-complication (#895). Webpack config is rather complex as it is, wrapping it in an API adds further complication. It also means that maintainers of this package will have to provide support for said API and handle additional issues as they arise, which I'm guessing will mostly be "how can I configure weird thing XYZ in webpacker?" I'm using the config from v2 in production, it's working quite well. |
Great 👍 Ahh right, the new API's are there to make life easy when setting values on config object but const environment = require('@rails/webpacker')
environment.config = // {} webpack config object
environment.config.set('resolve.extensions', ['.foo', '.bar'])
environment.config.set('output.filename', '[name].js')
environment.config.delete('output.chunkFilename')
environment.config.get('resolve')
// Just merge as you would do with webpack-merge
environment.config.merge({ output: {
filename: '[name].js'
}
}) We will document these and hopefully this will solve most of the cases out of the box. The major problem with v2 config was that whenever we changed anything inside Gem the user has to run |
Uh oh!
There was an error while loading. Please reload this page.
Greetings,
I just upgraded webpacker from v2 to v3 (fastest moving rails lib I know of!). One of the notable changes is that the configuration/loaders/plugins are all managed by
@rails/webpacker
. I'm guessing this was done such that the gem and configurations stay in sync (i.e. at 3.0.1, both look towebpacker.yml
for configuration, but this may change in the future). Makes a great deal of sense and it's a nifty feature.My Angular 1 application has a bunch of custom configuration, such as a custom loader and the
ngAnnotate
plugin. The best I could come up with in webpacker v3 world was:and (since plugin order matters)
To an extent these defeat the purpose of having the default configuration package, since they rely on the configuration being consistent.
babelLoader
has to exist, otherwise my angular loader wont be installed properly, but AFAIK the internals of@rails/webpacker
don't necessarily adhere to any API. I also don't trust maps to be ordered, so that's not an ideal data structure for a feature where order matters.My gut reaction was to just go back to my v2 configuration, which gave me the ultimate flexibility in configuration, but I don't know if anything was changed w/ regards to binding to the gem in v3 (like did the format of
webpacker.yml
change?).Options I can think of (that may already exist and I'm unaware of):
@rails/webpacker
toconfig/webpacker
so I can manipulate them manually. Whenever I bump the gem version I can regenerate these files and diff them. I do this often for other packages.@rails/webpacker
. For example, in v2configuration.js
hadconst configPath = resolve('config', 'webpacker.yml')
. This could be imported asconst { configPath } = require('@rails/webpacker/paths')
. With this I could write my own config that ties into the gem, but still offers maintainers flexibility.A combination of both would presumably be best, generate a default configuration that ties into an API exported by
@rails/webpacker
.Thanks for helping on this issue!
The text was updated successfully, but these errors were encountered: