Allow inline strategies

[bebraw]

I had a quick chat with Tobias about this. As it happens, it would be valuable to be able to define strategies inline so you could achieve something like this:

merge(
  require("webpack-preset-development"),
  require("webpack-preset-css-modules"),
  require("webpack-preset-separate-css")
)

Inline definitions would encode the information per preset since it's information we don't care about if we are merging presets.

Possible APIs:

const webpackPresetCSSModules = {
  module: {
    rules: {
      __append: [ ... ]
    }
  }
};

const webpackPresetSeparateCSS = {
  module: {
    rules: {
      __update: function(rules) {...}
    }
  }
};

React Immutability Helpers

---

I guess finding the right API is the hardest problem. Minimum implementation would convert the definition to the current API (adapter).

Feedback welcome!

[andywer]

Hi @bebraw. I would suggest using the immutability helper unless there is some strong reason not to.

I think it does everything that needs to be supported, there will be no fighting over the API details, a bunch of people will already be familiar with it and you don't even need to write much documentation. Just link to the immutability helper's docs :)

[bebraw]

I think I found something that would work well with the existing system without causing a lot of work:

const webpackPresetCSSModules = {
  module: [ ... ]
};
webpackPresetCSSModules._strategies = {
  'module.rules': 'append'
};

const webpackPresetSeparateCSS = {
  module: rules: {
    function(rules) {...}
  }
};
webpackPresetSeparateCSS._strategies = {
  'module.rules': 'replace'
};

_strategies would contain the hints merge would pick up. It would also delete the field in the process since it's just a hint (no value in the result).

Even though React's immutability helpers are powerful, this feels like a simpler API since it's just key-value pairs.

[bebraw]

@rockmacaca Any thoughts on this? This needs some direction.

I have been thinking about a different solution entirely. Maybe configuration parts need to own some dependency information. Then you could push them through a dependency resolver and figure out the correct order that way. It's a lower level solution, but it could work.

[kherock]

You'll need to detail that last thought a bit more clearly for me, not sure what you mean.

I do kind of like the hints. My first immediate thought toward a solution for plugin merging is something like the following:

const { LoaderOptionsPlugin } = require('webpack');
const webpackPresetMinimize = {
  plugins: [
    {
      __constructor: LoaderOptionsPlugin,
      minimize: true,
      options: { ... }
    }
  ]
};
// Smart merge could include this automatically
webpackPresetMinimize.plugins.__update = function (plugins) { ... }

Not too pretty, but I'd be ok with using it. It probably needs tweaking to support plugins that take multiple arguments. Something similar could probably be used for merging functions as well.

I do think the immutability helpers are great in that they accomplish most of what the existing "strategy" implementation does. There would still need to be additional work on top of the result to support merging plugin configs and function arguments.

[bebraw]

You'll need to detail that last thought a bit more clearly for me, not sure what you mean.

Consider something like CSS extraction and purifying. I have modeled these as extractCSS and purifyCSS functions myself. Latter depends on the former and they have to be defined in this specific order to work.

If purifyCSS could state this dependency, then the problem of ordering could be pushed to merge and you wouldn't have to care about the exact order as the user.

It can still be brittle, though, as the pipeline might be more complex than that.

I guess we might need more configurations to figure out a good way to handle this. The current solution (just vanilla merge) is totally enough for me.

I wonder if the smart variant even gives that great an advantage. You get something more compact out of it, but you could argue webpack itself should do that style of work to speed up execution. If there's no performance difference, providing smart merging isn't needed at all.

[magbicaleman]

I'm merging a base config, into dev config following this tutorial.

I've seperated my entry points;

dev.js

entry: [
      'react-hot-loader/patch',
      'webpack-dev-server/client?http://localhost:9900',
      'webpack/hot/only-dev-server',
      './src/index.js',
    ]

base.js

entry: [ './src/index.js' ],

When they get merged, it seems that the entry info from dev.js gets appended to base.js, which is understandable. The issue becomes that react-hot-loader/patch needs to be first.

I looked into strategy and this get's the desired result;

const a = webpackMerge.strategy({
  entry: 'prepend',
})({ entry: ['index.js'] }, { entry: ['react-hot-loader/patch'] });

// { entry: [ 'react-hot-loader/patch', 'index.js' ] }

If I wanted to accomplish this with merge(base.js, dev.js), I'm expecting the following to work, but perhaps I'm way off here

dev.js

entry: [
      'react-hot-loader/patch',
      'webpack-dev-server/client?http://localhost:9900',
      'webpack/hot/only-dev-server',
    ]```

base.js

entry: merge.strategy({
  entry: 'prepend',
})({ entry: ['index.js'] });,

So, I'm wondering if the proposition above would solve this. Alternatively, I could leave the base.js entry property blank, and add it to both dev.js and prod.js.

[bebraw]

@magbicaleman Yeah, this particular case is a little tricky. I've found it's easier not to inherit entries for this reason. Instead I manage them per target even if that might lead to some duplication. At least you can use a vanilla merge then and it's easy to see what's going on.

Note that 'react-hot-loader/patch' will inject an empty module during production once they get a new beta version out. That means you can likely have it in the entry configuration always and it will do the right thing.

[magbicaleman]

@bebraw

This is my current entry for dev.js now, might as well duplicate.

entry: [
      'react-hot-loader/patch',
      'webpack-dev-server/client?http://localhost:9900',
      'webpack/hot/only-dev-server',
      './src/index.js',
    ]

base.js

entry: [],

prod.js

entry: [
      './src/index.js',
    ]

My question is, do the following also need to be in prod.js;

 'react-hot-loader/patch',
 'webpack-dev-server/client?http://localhost:9900',
 'webpack/hot/only-dev-server',

[bebraw]

@magbicaleman You can skip

 'react-hot-loader/patch',
 'webpack-dev-server/client?http://localhost:9900',
 'webpack/hot/only-dev-server',

for production. Those last two entries could be skipped if you ran webpack-dev-server in inline mode but there's probably a reason why you are not.

I would write config like this:

dev.js

entry: [
      'react-hot-loader/patch',
      'webpack-dev-server/client?http://localhost:9900',
      'webpack/hot/only-dev-server',
      './src/index.js',
    ]

prod.js

entry: [
      './src/index.js',
    ]

If/when you have more app entries, you could push those somewhere and perhaps .concat them for development and consume directly for production. That would give entry: appEntries and entry: [... dev entries ...].concat(appEntries) which isn't too bad.

[magbicaleman]

@bebraw thank you very much for all of your feedback, I pretty much did end up with your recommendation above.