@easy-webpack: Same idea, similar execution

[niieani]

Hi @andywer,

I'm the author of easy-webpack, which, from the looks of it seems like the same idea as webpack-blocks, just executed by a different person. Am I correct in assuming you weren't aware of my project in July 2016 and thus started your own, or was there something about @easy-webpack that didn't satisfy your needs?

Looking through your project I saw some overlapping issues between our projects: the latest design of @easy-webpack uses a different solution to the ones proposed in #34, I've been struggling with the 'best design' for this myself.

Being the default configurator for the @aurelia framework, we also had some user complaints about how 'blackboxed' the configs are (i.e. it takes an effort to take them out when you reach a point a 'preset' is not enough; I imagine it's the same with webpack-blocks), so I had some thoughts on how to mitigate this for v3 of @easy-webpack by simply inlining the generated configs with a sort of virtual 'git' repository, marking edges of inlined presets in comments. I've also recently thought of a different concept for conditional configuration, like this, but I'm still thinking about the best way to solve both of these.

Would combining efforts make sense to you?

[andywer]

Hi @niieani!

No, I was not aware of easy-webpack, but thanks for the link. I guess the most difficult thing to achieve when building such a specific utility like easy-webpack, webpack-blocks, ... is to create the critical mass of attention necessary to make it popular, since it is very hard to google for a concept like this.

Yeah, the "webpack-merge or not" conflict is still not solved. On the one hand I like that when you create a block you just have to return a config snippet and that is it. That makes it easy to create blocks. On the other hand it makes it pretty much impossible to control the way it should be merged.

webpack-merge recently came up with "merge strategies" to address this particular issue, but it does not feel very elegant to me. So I would be glad to join forces concerning this issue, for instance, and discuss it together :)

About the "blackboxing"... I am not sure if I get what you mean. I suppose you mean that as a user you do not see which configuration is created by easy-webpack/webpack-blocks (so the processing and the result of the tool is the blackbox)?

Your ideas on how to address this seem interesting (haven't thought about creating a webpack config (as a file) and then using that), but I would still like to hide this complexity from the user.

My current process when debugging a webpack-blocks configuration is to just console.log() the result of createConfig() (the generated webpack config object) or specific parts of it. I had idea that it might be nice to be able to "pretty-print" the generated configuration (i.e. plugins: [ { definitions: { foo: '"foo"' } } ] => plugins: [ new webpack.DefinePlugin({ foo: '"foo"' }) ]) for debugging purposes.

How about discussing this blackboxing issue here in this issue a little further (if you want) and the webpack-merge thing in the already-opened issue?

[eliperelman]

I have a similar project as well, which was created because I also had a hard time finding anything that met the use cases I was looking for: webpack-chain.

As far as black-boxing in webpack-chain, each option type has a way to unserialize to a structure that Webpack recognizes. For the top-level, chain.toConfig() generates the entire config. Want just the rules? chain.rules.toConfig(). No part of the config is black-boxed.

Neutrino uses webpack-chain to merge configurations across all presets. It's able to do this because webpack-chain enforces identified parts; basically making you name the parts of the config that should be easily modified by a consumer:

const chain = neutrino.config; // this is a webpack-chain instance

// modify the options for a rules loader:
chain
  .rule('compile')
    .loader('babel', ({ options }) => {
      // modify/merge Babel options, then return
      return { options };
    });

// also works for plugins:
chain
  .plugin('copy', (Plugin, args) => {
    // Change the args to the plugin, and re-instantiate
    return new Plugin(...args);
  });

This let's others change deeply-nested configuration without needing to create large nested merge structures along the way if can be avoided. Hope this gives some insight into how other projects are trying to solve this. 😃

[sapegin]

About the "blackboxing"... I am not sure if I get what you mean. I suppose you mean that as a user you do not see which configuration is created by easy-webpack/webpack-blocks (so the processing and the result of the tool is the blackbox)?

That’s a real issue for me: I want to know which options will be used by each block to understand which options I should add to have a config I like. So far the only solution I see is to show an example of a config in the docs that will be generated by default.

Maybe we need something like React Styleguidist on webpack-blocks site where you could expand a resulting webpack config for each example.