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 mutating 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.

[seaneshbaugh]

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

I'm glad I managed to come across this issue. I was worried I was going about things in a hacky way. Still kind of am actually. I wanted to silence some warnings from sass since one of my dependencies (@materializecss/materialize) hasn't updated it's usage of map-has-key and map-get yet and ended up doing this in my config/webpack/webpack.config.js:

// See the shakacode/shakapacker README and docs directory for advice on customizing your webpackConfig.
const { generateWebpackConfig, merge } = require("shakapacker");

const options = {
  resolve: {
    extensions: [".scss", ".jpg", ".jpeg", ".gif", ".js", ".jsx", ".png"]
  }
};

const webpackConfig = generateWebpackConfig(options);

const sassRule = webpackConfig.module.rules.find((rule) => ".sass".match(rule.test));
const sassLoader = sassRule.use.find((use) => use.loader && use.loader.match(/sass-loader/));
const sassOptions = {
  quietDeps: true,
  silenceDeprecations: ["global-builtin"]
};

sassLoader.options.sassOptions = merge(sassLoader.options.sassOptions, sassOptions);

module.exports = webpackConfig;

Which produces the following options for the sass loader:

{
  sassOptions: {
    loadPaths: [],
    quietDeps: true,
    silenceDeprecations: [ 'global-builtin' ]
  }
}

Which is what I was aiming for.

From your comment Justin it sounds like this is the intended way of going about this sort of config change.

If that's the case, it might be a good idea to explicitly document a use case like mine. The readme does include a note at the end of the webpack config section (https://github.com/shakacode/shakapacker?tab=readme-ov-file#webpack-configuration) which mentions modifying a rule produced by the default config but it was not at all obvious to me that I could/should use this method for modifying the config for a loader (in hindsight it seems kind of obvious now though). I think a couple of more complex examples of changing the default config and explicitly calling out changing the config for a loader would do much to clear up any potential confusion here.

Edit: If my use case is how this is supposed to work and you think would make a good example in the readme I'd be happy to submit a PR.