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

Breaking webpack config change introduced in 1.9.162 #4044

Closed
robwierzbowski opened this issue Feb 14, 2018 · 4 comments
Closed

Breaking webpack config change introduced in 1.9.162 #4044

robwierzbowski opened this issue Feb 14, 2018 · 4 comments

Comments

@robwierzbowski
Copy link

robwierzbowski commented Feb 14, 2018

Description

Previously, Gatsby users were able to override loader excludes by specifying their own regex in gatsby-node.js. Example:

config.loader('js', {
  exclude: [/(node_modules(?!(\/some-package))|bower_components)/]
});

In 50b0a47, which was released in 1.9.162, exclude values in the Gatsby webpack.config.js were wrapped in an array.

If my co-worker and I are reading the source of webpack-configurator correctly, overrides to exclude will now be concatenated, where before they were replaced.

The most commonly documented method of excluding all but one node_module is a regex that excludes a package with a negative lookahead, like the code sample above. But since /node_modules/ is excluded in the base configuration, and Webpack excludes within an array are cumulative, that won't work anymore.

The author of 50b0a47 didn't run into this problem because they were adding additional excludes, not attempting to reduce the scope of existing excludes.

Environment

Gatsby version: 1.9.162+
Node.js version: Any
Operating System: Mac

Expected behavior

There should be a documented method for overriding loader configuration in arrays, specifically exclude.

A patch update doesn't introduce breaking changes 🙂.

It would be pleasant if Gatsby used a more widely used/understood/updated method of merging webpack configs like webpack-merge (used by the Vue team).

@bytheway875
Copy link

Confirmed that this can be "fixed" in the short term by implementing something like the poster of this issue did:

#3052

But this requires recreating the program variable, loading in the babelConfig, and wrapping the config stuff in a promise, removing the defaultloader, and then adding customconfig.


In my opinion, reverting the exclude to be a string that must be completely overwritten is the best short-term course of action in order to replicate the expected behavior as documented in the Gatsby docs.

@tech4him1
Copy link

tech4him1 commented Feb 15, 2018

The related PR to that commit is #3611.

cc/ @erquhart

@erquhart
Copy link
Contributor

erquhart commented Feb 15, 2018

@robwierzbowski passing config as a function or using a resolver function doesn't allow replacement?

https://github.com/lewie9021/webpack-configurator/blob/master/lib/mergeLoader.js#L16-L17

@erquhart
Copy link
Contributor

erquhart commented Feb 15, 2018

I should have prefaced my comment with: this was totally a breaking change and I overlooked use cases where that would be true, apologies for that. In light of the break, I believe reverting is the only proper course. I'll open a PR to do that now.

My comment above should then apply to cases that do need an array - webpack configurator accepts a function so that the existing value can be both accessed and replaced, regardless of value type. Of course, this is all a bit moot since any plugin can change any part of the webpack config to any value, so projects consuming plugins that do what I described will still need to use a function themselves to prepend values to the array.

Regarding using a better lib than webpack-configurator, that's also breaking, and the next opportunity for breaking changes should actually put everyone in far better shape than any traditional approach to extending webpack.

Cheers, and again, sorry for moving your cheese.

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