module.loaders is now module.rules

[stevenjlho]

According to the Migrating from v1 to v2, module.loaders is now module.rules, but this package still use module.loaders. Although it works, but i think it should use module.rules instead of module.loaders.

[andywer]

Hey @stevenjlho. Yes, that's true.

But since the majority of the blocks is supposed to work with webpack 1.x as well as webpack 2.x it seemed intuitive to still use module.loaders for now, since it works for both.

Another option might be to use module.rules and implement a compatibility layer transforming webpack 2 configs into webpack 1.x - compatible ones.

[jvanbruegge]

The "problem" is that webpack is throwing deprecation warnings:
fallbackLoader option has been deprecated - replace with "fallback" loader option has been deprecated - replace with "use"

[andywer]

Hmm, good point. I guess that means switching to webpack 2 API and writing a webpack 1.x - compatibility layer...

[sapegin]

Or detect user’s version of webpack.

[andywer]

@sapegin There is the context.webpackVersion now, so you could let the blocks decide. But I really don't want to go that way for a simple reason: You will basically end up with blocks consisting of a webpack 1.x and a webpack 2.x logic.

This would make unit testing way harder and might lead to issues like "works with webpack 2, but is buggy with webpack 1". So I think writing them all in webpack 2 - style and having a transparent compatibility layer in @webpack-blocks/webpack (doing the module.rules => module.loaders) is probably the best bet.

[stevenjlho]

I think @webpack-blocks/webpack can keep webpack1.x configuration, @webpack-blocks/webpack2 use webpack2.x configuration

[jvanbruegge]

@andywer Is there a rwason to support webpack 1 at all? I mean all it takes to update is use the webpack 2 block and extract-text2 block. No double work then

[andywer]

@stevenjlho The problem is not so much @webpack-blocks/webpack and @webpack-blocks/webpack2, but rather the Babel, PostCSS, TypeScript, ... blocks. I meant those when I said "You will basically end up with blocks consisting of a webpack 1.x and a webpack 2.x logic" :)

@jvanbruegge Good point, but I fear there might be too many people out there with legacy setups. The first stable webpack 2 version is just out for one month if I remember correctly. There might be incompatibilities. Or people are dependent on some custom stuff that is not webpack 2 - compatible.

In the long term there will probably only be a need for webpack 2, but I would not drop webpack 1 support yet.

[stevenjlho]

@andywer Hmm, you are right.

[jvanbruegge]

@andywer but isnt that abstracted away by the blocks anyway? Supoose you upload the blocks with a 2 in the name (e.g. webpack2, extractText2) without the 2 as new version of the legacy blocks. The people with old setups will get webpack2 without even noticing. I mean after all this is the purpose of this: Abstracting away quirky configuration of webpack

[jvanbruegge]

webpackVersion could be removed and all blocks having a special config can just depend on the new webpack block containing webpack2. It is as breaking as the 0.3 update in the sense, that you have to update all blocks, and not only one, but your config does not change at all

[andywer]

@jvanbruegge You have a point here and I would prefer that as well, but there is one problem:

Most of the blocks that exist twice, suffixed with a 2 and without, ship with pretty much exactly the same code. So in terms of code it is already abstracted away.

But: extractText (webpack 1.x version) depends on extract-text-webpack-plugin 1.x (package.json dependency). extractText2 depends on extract-text-webpack-plugin 2.x, since the breaking changes under the hood of webpack made a breaking change in the extract-text-webpack-plugin necessary.

There is just no way to declare conditional dependencies in the package.json.

[jvanbruegge]

Yeah, what I mean is that the new version would only depend on extract-text-webpack-plugin 2.X and only work with the new webpack block containing webpack 2.
People with old setups and old versions will still get extract-text 1 from npm, but everyone new and everyone updating his dependencies in the package.json will get the V2. You dont need any conditional dependencies.

[andywer]

But this solution is also known as dropping webpack 1.x support, isn't it? 😅

Maybe a twitter poll might help get some clarity here: "Should webpack-blocks drop webpack 1.x support in favor of consistent webpack 2 blocks in the near future?" or so :)

I would just fear that all the tech-hipsters are on twitter and the folks using it with webpack 1.x don't see the poll... 🙈😉

[jvanbruegge]

The question is, should they care? They want an easy config that works stable. How this is working shouldn't be relevant.

[sapegin]

Yeah, according to an internet poll 100% of people use internet :-)

[jvanbruegge]

They are not using webpack1, they are using webpack-blocks. They should not have to worry about the inner workings of the blocks

[andywer]

I was already thinking about writing a post about the two ways to use webpack-blocks, since I feel most people only realize one (maybe no one is even using it the 2nd way right now, don't know)...

1. Use webpack-blocks to set up a new webpack configuration, don't care about too much about the internals.
2. Use webpack-blocks to slice down your existing 200+ line configuration. It already works, but the monolith is pretty much unmaintainable in the long term. Turn it into blocks.

@jvanbruegge What you say is right for the majority of the scenario 1 users, but not for scenario 2. And one my core principles when building it was "extensibility first". I'd like it to be perfectly usable with plugins/loaders/... that are not in the webpack-blocks repo :)

I hope that is possible without unnecessarily complicating stuff.

[jvanbruegge]

Ok yeah, I didnt know there was anything like category 2.

[sapegin]

What if you use the same package name but make a major release for webpack 2 and users with webpack 1 will just continue using the previous version?

[andywer]

Yeah, I thought about this, too :)

Tightly coupling the block version to the webpack version might be an easy solution, but we haven't reached 1.0 yet, so this doesn't work for now. And once we do, we cannot really introduce major breaking changes anymore, since semver dictates a major version bump, thus getting the versions out of sync again :-/

[sapegin]

I’d not try to match versions exactly. Just the latest version of a block supports the latest version of webpack. It might be webpack-blocks 15 for webpack 7 ;-)

[jvanbruegge]

Yeah, I would not add abritrary constraints that dont add benefit

[andywer]

Fair enough!

So up next we would need to be confident enough to bump to 1.0 (first mature version) and as we do so split it into webpack-blocks 1.0 for webpack 1.x and webpack-blocks 2.0 for webpack 2.x.

Any other thoughts?

[stevenjlho]

It is a perfect solution

[stevenjlho]

I think webpack block 1.0 do not add new feature, just fix some bugs. And developing webpack block 2.0 primarily

[jvanbruegge]

Yes, make a V1 branch that is getting bugfixes and thus releases for WP1, and the master for WP2

[andywer]

Yeah, there is mainly one thing I am still thinking about:

Whether the createConfig() should provide so many defaults (and making createConfig.vanilla() necessary) or if createConfig.vanilla() should become the default createConfig() and all the default loaders should be moved to a basic preset like #60.

[andywer]

(Sorry if it takes longer to respond, but I will have more time in a few days)

[jvanbruegge]

Im in favor of the second.

[andywer]

Closing this issue, since 1.0 got you covered 😉