webpack-dev-server compatibility

[karolyi]

Hello,

does this module have support for webpack 5?

It doesn't seem so to me.

[fjsj]

It works both with 4 and 5. What issue are you seeing?
All django-webpack-loader examples that use webpack-bundle-tracker use webpack 5: https://github.com/django-webpack/django-webpack-loader/tree/master/examples

[karolyi]

Hm, I can't bring it to finish building.

As to why I don't know yet, I will have to look into it. For me it seemingly builds the modules (CPU load high), and then just doesn't finish. This all with the latest version of webpack 5.

[fjsj]

I see, we'll will try to reproduce with latest webpack 5.

[karolyi]

I can't reproduce my issue with the webpack tests, but that doesn't mean there's no error. The module tests use very old dependencies, any of them could have broken this module since I (at least I aim to) use the latest versions of modules.

I'm going to have to look deeper on my end.

[fjsj]

You mean old devDependencies, right? Some of them are old due to webpack 4 support. We can drop that in near future with a new major version release.

[karolyi]

So my initial investigation so far shows that even the modified code (which contains a lot of my originally rejected changes) wants to calculate integrity on _handleDone, but in my case the assets are not in there the filesystem where they are pointed to (probably because they're stored in the memory and not saved yet).

My version (that still works) uses the _handleAssetEmitted hook where the content is available and is not pulled from a file that is nonexistent: at which point webpack compilation just silently hangs without an error emitted.

I'm still using my version flawlessly, just wanted to try and give another go to this in the hopes of it being properly updated, which doesn't seem to be the case.

[karolyi]

Oh yeah, I remember now why files aren't stored: webpack-dev-server. It only keeps the files in memory.

[karolyi]

So I took the time today and made my fork run the tests. It involved plenty of fixes in the tests, but only one in lib/index.js which points out that my fork will work seamlessly with both webpack 4 AND 5, and with using webpack-dev-server too.

I still don't care about reformatting the code, just corrected and run all the tests to see if webpack4 would work, which I don't use.

[karolyi]

In case you don't find the fork: https://git.ksol.io/karolyi/webpack-bundle-tracker

[fjsj]

thanks, we'll investigate

[rvlb]

Hi @karolyi, we've been giving a look at this issue and managed to port over the changes from your fork to our branch (#132).

However, once we were testing the changes on the examples at django-webpack-loader (i.e.: https://github.com/django-webpack/django-webpack-loader/tree/master/examples/simple), we've noticed an issue where the assetEmitted hook call is skipped if the asset file has already created on disk on previous run (as in the examples, if it's already at the webpack_bundles output dir), which ends up creating an inconsistent stats file.

I've double-checked the examples using your fork code as-is and also detected the issue in that case. For both scenarios, however, the hot-reload example (https://github.com/django-webpack/django-webpack-loader/tree/master/examples/hot-reload) works flawlessly.

My question then is to double-check if this ended up showing up for on your setup and if it was something that you ended up solving with some webpack setting.

From our side, one possible solution we may end up trying to handle all cases is the following:
Use a different hook (i.e.: processAssets), which could end up bringing the original problem on calculating the integrity since the asset isn't written to disk at that point, but we could try reading from the in-memory data instead of reading from the disk

Let me know your thoughts on that. Thanks!

[karolyi]

Hey,

I've never faced this issue but also don't deny its existence. In my case I was using webpack-dev-server on my local dev env.

The pipeline I've built for compiling assets with gulp, always cleans the output files before building them, so they can't exist. Hence, I can't reproduce this test case in my environment.

Make of that what you will. I think the healthy way of building physical (non-in-memory) assets is to clean the output directory every time before doing it, at least that's what makes sense to me. Leaving the files there would imply some kind of an 'incremental' build.

[rvlb]

Integrity calculation has been revamped at #132, now we'll always use the content from the in-memory asset that webpack emits, which won't break with webpack-dev-server.

An example with a similar setting has been updated on the django-webpack-loader side https://github.com/django-webpack/django-webpack-loader/blob/v3.2.2/examples/hot-reload/webpack.config.js.