andywer/webpack-blocks

Order of execution is not obvious

jvanbruegge opened this issue · 6 comments

jvanbruegge commented

I create a config with webpack blocks that also includes a customConfig. That custom config should be able to overwrite previous values set by the blocks. Thus I placed the customConfig at the end of createConfig. But this did not work, because it seems that blocks within env are executed afterwards.
It would help a lot if the blocks would be evaluated in a recursive way, top to bottom.

andywer commented

Hey Jan. The blocks should already be run recursively, top-to-bottom if I am not mistaken.
Can you provide a short sample?

jvanbruegge commented

I had

createConfig([
    //...
    env('production', [
        devServer(),
        //...
    ]),
    customConfig({ devServer: { historyApiFallback: { /* options */ }}})
]);

and the custom config did not overwrite the historyApiFallback of the devServer.
While investigating, I printed the prevConfig and it was everything except the env blocks

andywer commented

Hey @jvanbruegge. Sorry, I forgot about this one... 🙊

Looks like the devServer block updates the config in its post hook, that's why it overrides your custom config.

We could make the customConfig block emit the config via a post hook as well, but then we would break scenarios like this one:

createConfig([
  customConfig(/* options */),
  someRandomBlockWithoutPostHook(/* options */)
])

Not sure how to deal with this...

Closing for now, since it looks like a "won't fix". But feel free to re-open if you have an idea.

jvanbruegge commented

I looked at the source, and the reason for the post hook seems to be the entry field. Why do we have to update the entry when using the dev server?

andywer commented

Yeah, I fear we have to in order to "patch" previously set entry points.

jvanbruegge commented

But why do we have to patch at all?