-
Notifications
You must be signed in to change notification settings - Fork 795
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: restore stats output target functionality. #3030
Conversation
@@ -26,7 +26,7 @@ export const generateSystem = async ( | |||
const results = await generateRollupOutput(rollupBuild, esmOpts, config, buildCtx.entryModules); | |||
if (results != null) { | |||
const destinations = systemOutputs.map((o) => o.esmDir); | |||
await generateLazyModules( | |||
buildCtx.systemComponentBundle = await generateLazyModules( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar scenario to src/compiler/output-targets/dist-lazy/generate-cjs.ts
@@ -60,15 +60,13 @@ export const outputLazy = async (config: d.Config, compilerCtx: d.CompilerCtx, b | |||
|
|||
const rollupBuild = await bundleOutput(config, compilerCtx, buildCtx, bundleOpts); | |||
if (rollupBuild != null) { | |||
const [componentBundle] = await Promise.all([ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Within this promise, the return signature in generateEsmBrowser was used and the others returned undefined. Refactoring to reset the buildCtx where the function does internal modifications felt like a better fit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will effectively serializes these outputs - do we have any measurements on how that impacts performance of the lazy build? If not, can we generate some?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lars generated some, but I'll write a node script to run a build 10 times to gather and report data.
@@ -260,7 +266,8 @@ export type BuildTask = any; | |||
|
|||
export type BuildStatus = 'pending' | 'error' | 'disabled' | 'default'; | |||
|
|||
export interface BuildStats { | |||
export interface CompilerBuildStats { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated this name because it would match the names of other typings. Also, it wasn't used anywhere.
src/compiler/build/build-stats.ts
Outdated
*/ | ||
export function generateBuildStats(config: d.Config, buildCtx: d.BuildCtx) { | ||
const buildResults = buildCtx.buildResults; | ||
let jsonData: any; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to avoid adding any
types if we can. This variable and the return of this function could be CompilerBuildStats | { diagnostics: d.Diagnostic[] }
. You could add a type for the union and/or { diagnostics: d.Diagnostic[] }
.
src/declarations/stencil-private.ts
Outdated
esmBrowserComponentBundle: BundleModule[]; | ||
esmComponentBundle: BundleModule[]; | ||
es5ComponentBundle: BundleModule[]; | ||
systemComponentBundle: BundleModule[]; | ||
commonJsComponentBundle: BundleModule[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was worried that adding these to the build context would increase the memory usage significantly. Luckily that is not the case. I ran 10 builds of ionic-framework using master
and this PR. The increase is relatively minor:
Build # | master |
#3030 |
---|---|---|
1 | MEM: 682.1MB | MEM: 658.6MB |
2 | MEM: 743.8MB | MEM: 677.3MB |
3 | MEM: 546.5MB | MEM: 757.6MB |
4 | MEM: 727.2MB | MEM: 697.9MB |
5 | MEM: 731.8MB | MEM: 658.1MB |
6 | MEM: 730.2MB | MEM: 656.2MB |
7 | MEM: 738.5MB | MEM: 749.1MB |
8 | MEM: 726.2MB | MEM: 655.7MB |
9 | MEM: 709.2MB | MEM: 684.9MB |
10 | MEM: 663.2MB | MEM: 617.7MB |
Average | MEM: 681.3MB | MEM: 699.9MB |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ltm is there a process you used for this that we could doc/reproduce in the future? I could see this also being useful for build times as well
src/compiler/build/build-stats.ts
Outdated
imports: bundle.rollupResult.imports, | ||
// code: bundle.rollupResult.code, // (use this to debug) | ||
// Currently, this number is inaccurate vs what seems to be on disk. | ||
byteSize: byteSize(bundle.rollupResult.code), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rwaskiewicz or @Lars, any recs about how to get this number to be more accurate without reading the file from disk? Should I omit for the time being?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How inaccurate are we talking? Like an order of magnitude? or a few bytes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, duh. It's because the files are compressed. It's a symptom of uglifying the files being applied after the build. Ironically, there's also some larger discrepancy between esmBrowser and esm as a result of esm not being minified. Since esm is not compressed right now (there's another bug somewhere filed about this...) the esm file's byte sizes produced at this point are accurate.
I think I'm going to rename this to "originalByteSize" instead. We should in the future figure out how to add that. Feels like an ordering problem. I'd hate to read files, as generating the stats may be much slower.
5eac36e
to
a58bc3c
Compare
Note: I'm not quite sure how best to test this exclusively within Jest, considering I don't know how to mock components to be compiled as a part of the compilerCtx/buildCtx during the Jest process. If you have any ideas don't hesitate to point me in the right direction! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have any plans to doc this as well? I noticed the checkbox in the PR summary was unchecked ATM
src/compiler/build/build-stats.ts
Outdated
import type * as d from '../../declarations'; | ||
|
||
/** | ||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor, the JSDocs in this file just seem to be stubbed out
@@ -25,7 +25,8 @@ export const generateCjs = async ( | |||
const results = await generateRollupOutput(rollupBuild, esmOpts, config, buildCtx.entryModules); | |||
if (results != null) { | |||
const destinations = cjsOutputs.map((o) => o.cjsDir); | |||
await generateLazyModules( | |||
|
|||
buildCtx.commonJsComponentBundle = await generateLazyModules( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we update the signature of the function to reflect we return something please? (and in the other files where we generate other module outputs for lazy)?
@@ -60,15 +60,13 @@ export const outputLazy = async (config: d.Config, compilerCtx: d.CompilerCtx, b | |||
|
|||
const rollupBuild = await bundleOutput(config, compilerCtx, buildCtx, bundleOpts); | |||
if (rollupBuild != null) { | |||
const [componentBundle] = await Promise.all([ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will effectively serializes these outputs - do we have any measurements on how that impacts performance of the lazy build? If not, can we generate some?
src/declarations/stencil-private.ts
Outdated
esmBrowserComponentBundle: BundleModule[]; | ||
esmComponentBundle: BundleModule[]; | ||
es5ComponentBundle: BundleModule[]; | ||
systemComponentBundle: BundleModule[]; | ||
commonJsComponentBundle: BundleModule[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ltm is there a process you used for this that we could doc/reproduce in the future? I could see this also being useful for build times as well
src/compiler/build/build-stats.ts
Outdated
imports: bundle.rollupResult.imports, | ||
// code: bundle.rollupResult.code, // (use this to debug) | ||
// Currently, this number is inaccurate vs what seems to be on disk. | ||
byteSize: byteSize(bundle.rollupResult.code), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How inaccurate are we talking? Like an order of magnitude? or a few bytes?
@rwaskiewicz Added your feedback! Had a couple conversation starters in your comments. Also, re: docs, yes I'd love to add them, but I don't think they should yet block this from being merged. I'd like to collaborate with Anthony on the content of the page. Something for next sprint I imagine. |
src/compiler/build/build-stats.ts
Outdated
const result = await config.sys.writeFile(outputTarget.file, JSON.stringify(data, null, 2)); | ||
|
||
if (result.error) { | ||
config.logger.warn([`Stats failed to write file to ${outputTarget.file}: ${result.error}`]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we verified this won't print
Stats failed to write file to [Object object]: [Object object]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
file should work fine, I removed the result.error so we can guard against that.
* @param compilerCtx | ||
* @param buildCtx | ||
* @returns | ||
* @param config the project build configuration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor, the summary is missing in these JSDocs
@splitinfinities regarding doc: I don't think we can merge this without docs. I think that needs to be a part of our definition of done |
ff607c0
to
d1e73fe
Compare
if (result.hasOwnProperty('compiler') && result.compiler.hasOwnProperty('version')) { | ||
delete result.compiler.version; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What value was this producing that we had to delete it and remove it from the assertion below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The version that's built at the moment of the test's build (it appended the date and time to the version)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, what was it that we changed here that made this suddenly fail?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It had been failing all along, actually, I just hadn't realized it because I didn't look into the build task on Github. My local build version wasn't failing because the timestamp hadn't changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess more concretely, what did we change in this PR to cause this to fail? Or are you saying it was failing since we turned tests back on in CI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean quite literally that all the tests in all of my previous commits failed on CI because the built compiler's version includes a timestamp, so I deleted the version that includes the timestamp so I don't have to test the object against that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha. Arguably, we should mock timestamp out, but I think that may be out of scope for this PR. Would you mind creating a ticket and adding it to the backlog?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
STENCIL-137
Stencil Site's related PR: https://github.com/ionic-team/stencil-site/pull/773/files |
buildCtx.buildResults = result.buildCtx.buildResults; | ||
buildCtx.components = result.buildCtx.components; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why we're doing this/what's going on here - can you explain this to me please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah! The components and buildResults are passed on to the buildCtx within this file from the resultant builds. These needed to be set on the buildCtx here because the promises don't update the buildCtx any more, and the original stats code needs to understand the state of the updated buildCtx after the promises all run. I wrote it this way so that we could keep the parallelization of the builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this affect the memory usage of Stencil in a negative way? I mean, I'm sure there's some cost associated with it, but do you have an idea of the order of magnitude?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect this comment still holds true, and may likely improve since I brought the parallelization back.
I was worried that adding these to the build context would increase the memory usage significantly. Luckily that is not the case. I ran 10 builds of ionic-framework using
master
and this PR. The increase is relatively minor:Build #
master
#3030
1 MEM: 682.1MB MEM: 658.6MB
2 MEM: 743.8MB MEM: 677.3MB
3 MEM: 546.5MB MEM: 757.6MB
4 MEM: 727.2MB MEM: 697.9MB
5 MEM: 731.8MB MEM: 658.1MB
6 MEM: 730.2MB MEM: 656.2MB
7 MEM: 738.5MB MEM: 749.1MB
8 MEM: 726.2MB MEM: 655.7MB
9 MEM: 709.2MB MEM: 684.9MB
10 MEM: 663.2MB MEM: 617.7MB
Average MEM: 681.3MB MEM: 699.9MB
Pull request checklist
Please check if your PR fulfills the following requirements:
npm run build
) was run locally and any changes were pushednpm test
) were run locally and passednpm run test.karma.prod
) were run locally and passednpm run format
) was run locally and passedPull request type
Please check the type of change your PR introduces:
What is the current behavior?
When the stats flag, or the stats output target was added to a consumers repo, the stencil-stats.json file was not generated.
GitHub Issue Number: #2926
Jira: STENCIL-43
What is the new behavior?
This file, when generated, provides a json file that folks can use in order to pull in what files were generated and how large those files were, as well as some of the configuration options passed to the compiler when it was invoked.
Does this introduce a breaking change?
Testing
Go check this app out: https://github.com/splitinfinities/stencil-build-stats
As well as this branch. Link them, and build. You'll see the stencil-stats.json file produce changes.
Other information
Stencil Site related PR: https://github.com/ionic-team/stencil-site/pull/773/files