You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Allow JSON and HTML output at the same time. #375
By the way, great work on this plugin. I don't have time right now to contribute this myself, but it would be a valuable addition to us and I just wanted to write the idea down somewhere. 😄
Thanks for the idea! I'm not sure if this works out nicely with all the possible options configurations — it looks like we could end up with configuration that is "invalid" and we would have to write quite a lot of error handling code to deal with this situation.
This produces at the same time stats.html and stats.json. Is this what you wanted to achieve?
No, because stats.json is from webpack, report of webpuck-bundle-analyzer is different. You can see at json html and compare it with stats.json - they are different, webpack bundle analyzer report contains information only about chunks
I think it is important feature.
I'm writing such script for two bundles comparsion:
Go to git branch
Build and analyze
Save report to temp folder
Go to other git branch
Build and analyze
Save report to temp folder
Compare two reports.
The issue is that I want to have html reports, but I also need reports in json format to be able to compare reports.
There are no beautiful ways to do it: parse html file to get json from it or build twice using different modes. @valscion I think it could be very goo to have ability to pass array to "mode" property:
new BundleAnalyzerPlugin({
analyzerMode: ['json', 'static'],
}),
The expected result is to have to files in build directory: report.html and report.json.
Maybe one of the ways to make it more easy is to not add report-json inline in html (window.chartData), but include it on html page using <script> where src is 'report.json' that is in the same folder. With this changes in static and server modes we always will have json to analyze
Maybe one of the ways to make it more easy is to not add report-json inline in html, but include it on html page using <script> where src is 'report.json' that is in the same folder. With this changes in static and server modes we always will have json to analyze
I don't think we need to do that. It would make the handling of report files more difficult as then the report would not be self-contained in a single HTML file anymore, like it now is. At any rate, we could discuss this change as its own change request, outside of the scope of supporting analyzerMode being an array.
Sorry, I don't have a lot of time currently, but as a workaround, you can also generate your own html file:
Published webpack-bundle-analyzer has a file called: webpack-bundle-analyzer/public/viewer.js
That file tries to read window.chartData. If you create a HTML file with the json data set to the window.chartData, and include the script file it should render correctly.
const { getViewerData } = require("webpack-bundle-analyzer/lib/analyzer");
const stats = require("./dist/stats.json");
async function main() {
const report = await getViewerData(stats);
console.log(report) ; // report.json that can be used for two bundles comparing
}
main();
Hmm yeah, I think adding support for analyzerMode possibly being an array would be reasonable.
Well, I think we can do that, but it will require a change to reportFilename option to be able to return different filenames for different report types e.g. allow to make it a function (reportType) => <reportFilename> (which won't work for CLI) or an object {<reportType>: <reportFilename>}. Anyway, options becomes a mess... We definitely need to ship a new major version with completely revised API with pluggable external reporters.
const { getViewerData } = require("webpack-bundle-analyzer/lib/analyzer");
const stats = require("./dist/stats.json");
async function main() {
const report = await getViewerData(stats);
console.log(report) ; // report.json that can be used for two bundles comparing
}
main();
thanks a lot!
Do note that you are relying on internal logic and this logic can break even in patch releases. I'm glad that it works for you, though ☺️
We definitely need to ship a new major version with completely revised API with pluggable external reporters.
Yeah, this does indeed sound like it.
So this isn't a trivial update in the end. It would require quite a lot of effort, so don't hold your breath 😅
Really looking forward to this! For now it seems we either have to resort to adding the plugin twice, or disabling it to generate the stats file and then using the CLI.
Activity
leipert commentedon Aug 11, 2020
By the way, great work on this plugin. I don't have time right now to contribute this myself, but it would be a valuable addition to us and I just wanted to write the idea down somewhere. 😄
leipert commentedon Aug 11, 2020
/cc @Gongreg
Gongreg commentedon Aug 11, 2020
Hey, I think it makes sense, but we should get @valscion opinion on it :)
valscion commentedon Aug 12, 2020
Thanks for the idea! I'm not sure if this works out nicely with all the possible options configurations — it looks like we could end up with configuration that is "invalid" and we would have to write quite a lot of error handling code to deal with this situation.
pkuczynski commentedon Nov 5, 2020
I believe this is possible already. Here is my example setup:
This produces at the same time
stats.htmlandstats.json. Is this what you wanted to achieve?alex-knyazev commentedon Apr 28, 2021
@
No, because stats.json is from webpack, report of webpuck-bundle-analyzer is different. You can see at json html and compare it with stats.json - they are different, webpack bundle analyzer report contains information only about chunks
alex-knyazev commentedon Apr 28, 2021
I think it is important feature.
I'm writing such script for two bundles comparsion:
The issue is that I want to have html reports, but I also need reports in json format to be able to compare reports.
There are no beautiful ways to do it: parse html file to get json from it or build twice using different modes.
@valscion I think it could be very goo to have ability to pass array to "mode" property:
The expected result is to have to files in build directory:
report.htmlandreport.json.Maybe one of the ways to make it more easy is to not add report-json inline in html (window.chartData), but include it on html page using <script> where src is 'report.json' that is in the same folder. With this changes in static and server modes we always will have json to analyze
valscion commentedon Apr 28, 2021
Hmm yeah, I think adding support for
analyzerModepossibly being an array would be reasonable.What do you think, @th0r?
valscion commentedon Apr 28, 2021
Also regarding this:
I don't think we need to do that. It would make the handling of report files more difficult as then the report would not be self-contained in a single HTML file anymore, like it now is. At any rate, we could discuss this change as its own change request, outside of the scope of supporting
analyzerModebeing an array.Gongreg commentedon Apr 28, 2021
Sorry, I don't have a lot of time currently, but as a workaround, you can also generate your own html file:
Published webpack-bundle-analyzer has a file called:
webpack-bundle-analyzer/public/viewer.jsThat file tries to read
window.chartData. If you create a HTML file with the json data set to thewindow.chartData, and include the script file it should render correctly.alex-knyazev commentedon Apr 28, 2021
@valscion @Gongreg
For now I came to this solution:
thanks a lot!
th0r commentedon Apr 28, 2021
Well, I think we can do that, but it will require a change to
reportFilenameoption to be able to return different filenames for different report types e.g. allow to make it a function(reportType) => <reportFilename>(which won't work for CLI) or an object{<reportType>: <reportFilename>}. Anyway, options becomes a mess... We definitely need to ship a new major version with completely revised API with pluggable external reporters.valscion commentedon Apr 28, 2021
Do note that you are relying on internal logic and this logic can break even in patch releases. I'm glad that it works for you, though☺️
Yeah, this does indeed sound like it.
So this isn't a trivial update in the end. It would require quite a lot of effort, so don't hold your breath 😅
leipert commentedon May 5, 2021
@valscion Submitted a PR with a backwards-compatible implementation: #442
langri-sha commentedon Apr 28, 2022
Really looking forward to this! For now it seems we either have to resort to adding the plugin twice, or disabling it to generate the stats file and then using the CLI.