-
Notifications
You must be signed in to change notification settings - Fork 28
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
Emit ES2020 builds for newer browsers, and emit ES5 for older browsers. #89
Conversation
@justingrant I know we've had a bunch of problems around build artifact output, and while I've tried this out myself against serverless and a minimal React build I'd love to know if this change causes you any issues with your projects. My understanding is that while it was common to ship ES5 in all the package bundles, there's no way to "un-transpile" if your target environment can use newer language versions, so there's a shift to ship newer code in packages? Does that match your understanding? |
I'll try this out tomorrow.
Hmm, I'm not sure what the circa-2021 best practice is. Any idea how we'd find out? Also, there's some Test262 failures. Expected? |
I'll look at these tomorrow - I was half expecting something to break but didn't feel like waiting around for the results... :) R.e. best practices - I vaguely recall being sent a webpage a while back detailing various good OSS build setups, but I've mis-placed it. I'll see if I can find it. It was created by Chrome DevRel with the collaboration of the various packaging tool maintainers, so I'd hope it's reasonably up to date. |
Fixed the 262 tests - turns out they fail if we pass it transpiled ES5 output or optimized output. Different set of failures for both cases. Do we care about these forms of failure? Some of the failures I think are expected:
|
We discussed in today's champions' meeting. Consensus:
One complexity with (3b) is that we will have
We thought it would be good to understand these failures more and to see if we could adjust terser to prevent these failures without a large bad impact on bundle size. If that's not possible, then we could use the same @12wrigja, what do you think about the above? The other question I guess is how far back we want to transpile. ES5? Later? I don't have a strong opinion about this, but I assume there are some Google standards for this? |
Currently, the default transpilation output is ES5 for most things at Google. Some teams emit code at newer language versions if the browsers they support can run it. Agreed r.e. Terser + the other Test262 setup - I'll try and look into this all soon.
I didn't realize that this would get discussed given I had filed it so close to the meeting 😅
For the UMD bundle, this makes sense. For ESM and CJS builds I don't think that makes sense given that if they are being dynamically included they wouldn't function properly anyways (and if they did then doesn't that mean the browser supports a language version > ES5)? |
@12wrigja, this makes sense, but I don't know enough about the topic to agree or disagree. Are there folks at Google you could ask about this? @pipobscure this was your feedback from this morning, want to add anything? |
ES5 sounds reasonable. |
I've filed #91 to report the current state of 262 tests on that output, and to track improving it. Getting the test suite to run against the optimized output is pretty easy but fixing the optimization problems seems to be quite difficult, so my current plan is to:
I still think this PR (with the second 262 run included) should block cutting releases, but the latter improvements should not. Thoughts? |
Agreed. Sounds good. Thanks for digging into this. |
eb8a9fa
to
fbab7d1
Compare
Ok - I've setup two more test262 runs - one for an "optimized" build (representative of the ESM/CJS bundle being optimized by Terser only), and an "es5" build (representative of the UMD bundle). There are separate expected-failures lists for each bundle, with expected-failures.txt always being used (e.g. to house tests that will fail for all test types e.g. due to bad mathematics, etc). |
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.
LGTM!
Another option that I didn't think of the other day, could be to not have expected-failures-es5.txt, and just set the test262-es5 job to not be required to pass. But this seems just as fine to me, and in fact more granular.
I think I'd prefer to know that at least all the mathematical logic / other functionality works, even if for ES5 we can't get certain tests to pass that some users are probably not interested in (e.g. length of functions, the descriptor's name, etc). Interestingly, it seems the ES5 version is faster as well? 7m vs 9m for the "debug" build (no optimization at all, just transpilation from TS to ES2020 JS). |
@justingrant Do you think you'll have time to look at these build artifacts in your projects at some point soon? |
I built an npm package (using |
Fantastic! I'm going to merge this, then sync up and new changes from the proposal and then we can release? |
Yep, sounds good. Don't forget to merge #93 before release too. Thx! |
Fixes #87.