[WIP] Use mini-css-extract-plugin@^0.7.0 and embed webpack-manifest-plugin into Encore

[Lyrkan]

A while ago we were forced to pin mini-css-extract-plugin to <0.4.2 because >=0.4.3 is not compatible with the current version of webpack-manifest-plugin (see shellscape/webpack-manifest-plugin#167).

Since the webpack-manifest-plugin hasn't been updated for quite a long time I suggest that we go back to what we did previously: embed it directly into Encore and apply the patch from shellscape/webpack-manifest-plugin#176.

At the same time the PR will:

• update mini-css-extract-plugin to ^0.6.0 ^0.7.0
• enable HMR in it when needed (--hot)
• add a configureMiniCssExtractPlugin(...) method that allows to configure both the loader and the plugin

In terms of BC, it could have some impacts since the plugin won't be an instance of webpack-manifest-plugin anymore. The mini-css-extract-plugin part however doesn't seem to introduce any BC break (only bug fixes and new features).

Closes #415

[Lyrkan]

Looks like there is an issue with the hashes in filenames, it doesn't use the same ones for my env (on which tests are all greens), Travis and AppVeyor.

I'll try to see if I can find out why...

[Lyrkan]

I think that's related to webpack-contrib/mini-css-extract-plugin#308

The issue was introduced by mini-css-extract-plugin@^0.4.4 and causes the hashes to change depending on the full paths of the files...

Let's put this PR on hold for now :)

[Lyrkan]

In the meantime I enabled HMR on the mini-css-extract-plugin by default when Encore is called with --hot and added an Encore.configureMiniCssExtractPlugin method:

Encore.configureMiniCssExtractPlugin(
  loaderOptions => {
    // change loader options here
  },
  pluginOptions => {
    // change plugin options here (optional)
  }
);

[tianyong90]

👍 Really ood job. I guess HMR will work for CSS after this PR.

[Lyrkan]

I guess HMR will work for CSS after this PR.

@tianyong90 You should actually already be able to use HMR with CSS by disabling the part that extracts styles to files, for instance:

if (Encore.isDevServer()) {
  Encore.disableCssExtraction();
}

[tianyong90]

@Lyrkan Thank you! I just start using encore yesterday (in fact I have stared it for nearly a year), I use it in my Laravel project and I think it much better than laravel-mix which I used for years. 😄

I've tried just now, but it did not work yet. I modified my css and the hot-update.js file loaded successfully, however the page style did not change.

[Kocal]

You should actually already be able to use HMR with CSS by disabling the part that extracts styles to files, for instance:

This need to be documented IMO

[Lyrkan]

I've tried just now, but it did not work yet. I modified my css and the hot-update.js file loaded successfully, however the page style did not change.

I'll have to take a look at it but last time I tried doing that it was working fine.

This need to be documented IMO

I was planning to add a boolean parameter to disableCssExtraction() (@weaverryan suggested it in another issue) before doing that:

Encore.disableCssExtraction(Encore.isDevServer());

Merging this PR would probably a best solution for HMR but I think the inconsistent hashes issue hasn't been fixed yet on mini-css-extract-plugin's side

[Kocal]

I was planning to add a boolean parameter to disableCssExtraction()

I'm not really a big fan. disableCssExtraction(true) means disable and disableCssExtraction(false) means don't disable? 🤔

I can understand this parameter is here to not breaking methods chaining, but I really think adding a enable/disable parameter to a method that disable something is wrong.

Instead, maybe we can do something like Encore.configureCssExtraction({ enable: !Encore.isDevServer())?

[Lyrkan]

I read it more like:

• disableCssExtraction(true) => "do I want to disable CSS extraction? yes"
• disableCssExtraction(false) => "do I want to disable CSS extraction? no"

Kind of the same way we already have enableVersioning(false) or enableSourceMaps(false) (but Encore.enableCssExtraction() wouldn't make much sense since it is already enabled by default)

[Lyrkan]

Rebased and changed the mini-css-extract-plugin version to ^0.7.0, but sadly the hashes issue is still a thing:

• on my env:

0.90edc8e8.js
0.6ba897e2.css
bg.76e19b0d.css
entrypoints.json
h1.6ba897e2.css
main.4a5effdb.js
manifest.json
runtime.c4afe823.js

• on Travis:

0.b71d4149.css
0.e7a12d6d.js
bg.e225dd24.css
entrypoints.json
h1.b71d4149.css
main.4a5effdb.js
manifest.json
runtime.982f7d96.js

• on AppVeyor:

0.7f1904a2.js
0.fefbda8e.css
bg.c1fc7b6d.css
entrypoints.json
h1.fefbda8e.css
main.4a5effdb.js
manifest.json
runtime.346dea91.js

[Lyrkan]

Still an issue... so I added a commit that makes the failing test less strict regarding hashes: it will still check that the expected files are generated but all hashes will be accepted.

I'm not sure that's the best thing to do since having inconsistent filenames between environments can be really annoying... but that's an option if we really want to update the mini-css-extract-plugin.

[weaverryan]

Sorry for letting this sit. I just addressed the hash test problem.

In general, does this have anything blocking it? What's the status of the HMR? About the disableCssExtraction(true) thing (because it would indeed be confusing), one option is to use enableCssExtraction() or enableCssExtraction(false). If we did this, we should probably deprecate the automatic extraction of CSS files. What I mean is, if you don't explicitly call enableCssExtraction(), we would trigger a deprecation warning. The idea is that we would make this part of THEIR config so that it's more explicit.

But... I only want to do this if there is a good reason to disable extraction (like, HMR basically does NOT work without it). And, I'd probably rename it to extractCssToExternalFiles(). But mostly... I would just like HMR to work without the user needing to worry about this ;).

[weaverryan]

So the unstable hashes only affect this test? Is it the only one where we have versioning enabled and are checking for CSS paths? If so, I'm ok cool with this... it's not ideal... because we'd like to know if hashes are changing unnecessarily... but we need to be pragmatic and nobody can think of a better solution :).

Could we refactor this into a reusable function... more for clarity than reusability - something on webpackAssert?

[Lyrkan]

Hey @weaverryan,

In general, does this have anything blocking it?

Depending on who you ask the hashes could be considered a blocking thing since it prevents having reproducible builds under certains conditions. But that's the only negative thing I see right now.

What's the status of the HMR?

Last time I checked it was working out of the box when using --hot.

What I mean is, if you don't explicitly call enableCssExtraction(), we would trigger a deprecation warning. The idea is that we would make this part of THEIR config so that it's more explicit.

I'm not sure adding mandatory methods is a good idea... especially since you could be using Encore to only handle JS files, in which case it wouldn't make sense to be forced to setup a CSS-related thing.

But... I only want to do this if there is a good reason to disable extraction (like, HMR basically does NOT work without it).

That shouldn't be needed for HMR if this PR is merged, and if someone really has to do it for another reason that's still doable using Encore.disableCssExtraction()... just not in a fluent way.

[Lyrkan]

Closing this PR in favor of #645 since it doesn't seem to have the annoying inconsistent hashes issue.

We could always reopen it if the other one doesn't get into a mergeable state fast enough.