Easier granular opt-out of defaults

[dleavitt]

Ruby version: 3.1.1
Rails version: 7.0.2
Webpacker version: 6.1.1

Desired behavior:
I want to tweak the style-loader options ¹ but otherwise opt-in to the excellent webpack defaults provided.

Actual behavior:
As far as I can tell it's a little harder to do this now that loaders/plugins etc aren't named. I'm currently digging through the list of rules and matching on the "test" values, then mutation them, which feels a little fragile (esp b/c webpack is so flexible in how it lets you define configuration.)

Some ideas:

• Fancier moduleExists: right now this function is used pretty heavily to determine what defaults to use. Instead of just checking for the existence of a module, it could tie in with some config and always return false if the user wants to opt-out of certain defaults.
• More use of getCustomConfig: swc and esbuild integrations allow the user to add a specially named config file within their app that can override defaults (littering the config folder with js snippets doesn't seem great though, see below.)

How does the user specify the config?

• Add more options to webpacker.yml: this is done right now for a few options (inline_css, webpack_loader) but maybe better to keep this file mostly about things ruby and webpack both need to know about.
• Have shakapacker export a function that takes some user config options and returns a default webpack config with those applied.

Alternatively:

• Document some specific recipes using webpack-merge to accomplish this, to the extent it is supported.
• Add some names or other metadata to defaults for easier manipulation (to the extent webpack supports doing so.)

Footnotes

1. Specifically I want to add a nonce so that its HMR functionality doesn't create a bunch of spurious CSP violations. ↩

[justin808]

@dleavitt I appreciate this work!

The current system relies on webpack-merge and plain JS coding on top of the base defaults.

I'm concerned that we create too many alternatives for accomplishing the same thing.

Let's think about this some more.

And some doc example recipes should always be appreciated!

[justin808]

Fancier moduleExists: right now this function is used pretty heavily to determine what defaults to use. Instead of just checking for the existence of a module, it could tie in with some config and always return false if the user wants to opt-out of certain defaults.

I thought a bit more about this. I agree that it might be nice to allow including some module but opting out of the default customization. webpack-merge is great for adding some configuration, but it might not conveniently remove the extra parts added just because a module was included.

[tomdracz]

I'll take a stab at the docs with the examples of customisation. Will also document what are the default rules.

Add some names or other metadata to defaults for easier manipulation (to the extent webpack supports doing so.)

Seems like great thing to do, if possible. Being able to reference rules based on some name rather than trying to find it by the rule test should simplify this a bit.

@justin808 In #87 (comment) you've mentioned an idea of webpacker.yml section. Would be good to get more thoughts on the configuration and API here.

[justin808]

@jherdman @dleavitt if any of you can get a PR submitted, I promise that my team will review it ASAP and we'll ship a release ASAP as well.

[dleavitt]

Thanks @justin808! Not sure if I'll get around to it this week but definitely something I'd be happy to help with or review.

[Judahmeek]

Closed as stale.

[justin808]

@dleavitt we could also create a "discussion" on doc issues.