plugin use infrastructureLogger and output the report.html to compiler.outputFileSystem #477

wood1986 · 2021-10-11T08:32:19Z

fix #476

src/viewer.js

src/BundleAnalyzerPlugin.js

package.json

src/BundleAnalyzerPlugin.js

valscion · 2021-10-11T11:57:26Z

src/BundleAnalyzerPlugin.js

    const done = (stats, callback) => {
+      const isFromWebpackDevServer = process.env.WEBPACK_SERVE === 'true';


Is there any other way than looking up an environment variable to figure this out?

We should not rely on this, always use compiler.outputFileSystem, because webpack uses compiler.outputFileSystem to write assets, so you can read them using the same fs

Hey @alexander-akait, I am unable to do this directly without webpack-dev-server check

this.fs = compiler.outputFileSystem

because of this

Otherwise,

webpack-bundle-analyzer/src/viewer.js

Lines 148 to 149 in 8dce252

fs.mkdirSync(path.dirname(reportFilepath), {recursive: true});

fs.writeFileSync(reportFilepath, reportHtml);

will break the tests

and this is webpack v4 specific

hm, for webpack v5, we have these methods? I mean use compiler.outputFileSystem for webpack v5, and keep old behavior for webpack v4

It means we write file again, need debug and search where we do it

the implementation of MemoryFS does not support recursively create folder. See this

according to the package-lock.json, the version of memory-fs is using 0.4.1

memory-fs used only by webpack@4, we should use require('fs') for webpack v4

Ok. I did what you have suggested and fixed the file already exist issue

I still need you help for the test. I have updated dev-server.js. For some reason, I am unable to get the test passed for {writeToDisk: true}.

It always use MemoryFileSystem and I do not know how to fix

src/BundleAnalyzerPlugin.js

valscion · 2021-10-12T07:22:27Z

I hope you won't get discouraged by the dev-server tests hanging when running in GitHub actions CI 😓.

I spent a great deal of time in figuring out why the dev-server related tests were always hanging in CI and not on my own machine and the only fix that seemed to work was this one: 55f3478. If you check 36e960b and the commits leading up to it, you can see my failed attempts at figuring out different alternatives which just didn't seem to work in CI.

If you manage to get the tests to not hang in CI, that would be amazing. I had a pretty bad time debugging those failures myself.

I cancelled the workflow run now as it was hanging.

wood1986 · 2021-10-12T07:43:08Z

@valscion. I think the hanging up issue is because the second expect is failed. Then it stops executing the rest. If it can execute to the end, it will not hang up and finish quickly.

wood1986 · 2021-10-12T07:49:21Z

Even with classic function (done) it will still block from executing to the end if one of the expect is failed. Then it will still leave the never ended server. Jest cannot exit

valscion · 2021-10-12T07:52:00Z

Oh right, you removed the jest.setTimeout part.

alexander-akait

Code looks good, let's fix tests and I think we can merge

.gitignore

src/BundleAnalyzerPlugin.js

th0r · 2021-10-12T15:00:54Z

src/BundleAnalyzerPlugin.js

@@ -72,15 +74,18 @@ class BundleAnalyzerPlugin {
    };

    if (compiler.hooks) {
-      compiler.hooks.done.tapAsync('webpack-bundle-analyzer', done);
+      compiler.hooks.compilation.tap(PLUGIN_NAME, (compilation) => {
+        this.logger = compilation.getLogger(PLUGIN_NAME);


So, logLevel option won't work anymore?

As the launch is always from webpack, it will use webpack.config.js level setting. See https://v4.webpack.js.org/configuration/stats/#statslogging and https://webpack.js.org/configuration/stats/#statslogging

bin/analyzer still can have its own log level

We need to update readme in this case and remove logLevel option from this list as it will be ignored.

I have just realized for webpack compiler without using hooks, it will fallback to your own logger. I do not know which version is not using hooks

src/BundleAnalyzerPlugin.js

src/viewer.js

wood1986 · 2021-10-12T18:13:23Z

test/dev-server.js

-      devServer.kill();
-      done(errorMessage ? new Error(errorMessage) : null);
-    }
+  it.skip('should save report file to the output directory when writeToDisk is true', async function () {


Almost complete. This is the test I was talking about in our long conversation with @alexander-akait. And I need some help for this one. Currently, I skip because I do not want to waste the time in the build machine.

What is the problem here?

When I specific devServer: { writeToDisk: true } in the webpack.config.js, it should output to disk. But it is still in the memoryFS because of the following, it always go to the last else statement

I have just figured out the reason why it always output to MemoryFileSystem when {writeToDisk: true}. webpack-dev-middleware is using compiler.hooks.assetEmitted when a file is assetEmitted to MemoryFileSystem, it will also emit to disk. But webpack-bundle-analyzer is not emitting the report.html or stats.json via the compiler.emitAssets So it never output to disk

The correct logic should be this

this.fs = compiler.webpack ? compiler.outputFileSystem : require('fs'); if ((process.env.WEBPACK_DEV_SERVER === 'true' || process.env.WEBPACK_SERVE === 'true') && (compiler.options.devServer?.writeToDisk || compiler.options.devServer?.devMiddleware?.writeToDisk)) { this.fs = require('fs'); }

No, it is not problem with webpack-bundle-analyzer, webpack-dev-middleware for the writeToDisk option should create layer fs, it is already tracked, no need to change something here

Then how to get {writeToDisk: true} works if it is not the problem?

…compiler.outputFileSystem

th0r · 2021-10-13T10:49:29Z

@wood1986 may I kindly ask you to:

Fix PR review issues in a separate commits and don't use force-push as it's really difficult to track changes you've made
Don't resolve my comments - I would like to do this myself.

wood1986 · 2021-10-13T16:44:26Z

@wood1986 may I kindly ask you to:

Fix PR review issues in a separate commits and don't use force-push as it's really difficult to track changes you've made

Don't resolve my comments - I would like to do this myself.

No problem

I thought this is a very tiny and it should be very quick to check all the check again
I usually use the resolve to let comment owner know I have completed. Meanwhile it will be easy for me to see what things left.

I will do what you ask

alexander-akait · 2021-11-05T12:40:58Z

@th0r @valscion What we need to finish it?

wood1986 commented Oct 11, 2021

View reviewed changes

src/viewer.js Show resolved Hide resolved

wood1986 commented Oct 11, 2021

View reviewed changes