Skip to content

Pre-process all ES5 builds #2840

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

Merged
merged 9 commits into from
Apr 1, 2020
Merged

Pre-process all ES5 builds #2840

merged 9 commits into from
Apr 1, 2020

Conversation

schmidt-sebastian
Copy link
Contributor

@schmidt-sebastian schmidt-sebastian commented Mar 31, 2020

@Feiyang1 I have to test these builds but this might enable tree-shaking in ES3/5 builds. I got this to work by using two different rollup phases.

@google-oss-bot
Copy link
Contributor

google-oss-bot commented Mar 31, 2020

Binary Size Report

Affected SDKs

SDKTypeBase (d9b599f)Head (982bbc1)Diff
@firebase/firestore/memorybrowser223866.00212770.00-11096.00 (-4.96%)
module221046.00211136.00-9910.00 (-4.48%)
main396522.00376777.00-19745.00 (-4.98%)
@firebase/firestorebrowser270246.00269110.00-1136.00 (-0.42%)
module267025.00267081.00+56.00 (+0.02%)
main487081.00487448.00+367.00 (+0.08%)
firebasefirebase.js846074.00846328.00+254.00 (+0.03%)
firebase-firestore.memory.js266153.00256172.00-9981.00 (-3.75%)
firebase-firestore.js311197.00311240.00+43.00 (+0.01%)
Metric Unit: byte

Test Logs

@Feiyang1
Copy link
Member

LGTM. I'm glad (surprised?) to see that it reduces the memory only build significantly. It's also interesting to see that the size of firebase-firestore.js and firebase.js increased a tiny bit, probably because the mangling is done indirectly now for cjs and es5 builds? In that case, I don't think it is a problem.

@schmidt-sebastian
Copy link
Contributor Author

schmidt-sebastian commented Mar 31, 2020

Validation checklist:

[x] Browser builds are mangled
[x] Node builds are not mangled
[x] Non-ES2017 builds are ES3.
[x] ES2017 builds are ES2017
[X] firebase.js works
[X] firebase-firestore.js works
[X] firebase-firestore.memory.js works
[x] Node build works in Node 6
[x] Node memory-only build works in Node 6
[x] CJS build works in browser
[x] CJS memory-build works in browser
[x] ESM build works in browser
[x] ESM memory-build works in browser
[x] All builds have sourcemaps

@schmidt-sebastian
Copy link
Contributor Author

@Feiyang1 This should now be ready for an actual review. I manually tested all builds.

@@ -45,6 +48,10 @@ import {
// The in-memory builds are roughly 130 KB smaller, but throw an exception
// for calls to `enablePersistence()` or `clearPersistence()`.
//
// We use two different rollup pipelines to take advantage of tree shaking in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably mention that it's because rollup is not able to treeshake Typescript classes compiled to ES5.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

},
include: ['dist/*.js']
}),
terser({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need terser again here since we already do it with the same options (comments: all, beautify: true) when producing esm2017 builds?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the size went up without Terser here, but I will do another round to verify.

Update: The size without Terser is about 4% larger (which I don't quite understand either, since we Terser again before computing the size). I added it back.

Copy link
Member

@Feiyang1 Feiyang1 Apr 1, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, we are not doing property mangling here, and we don't care about the size saving by mangling variable names. Developers will do them when building their apps.
Removing terser here can save some build time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, removed.

import memoryPkg from './memory/package.json';

// This file defines the second rollup pipeline and transpiles the ES2017 SDK
// into ES3 code. By splitting the build process into two independent build
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be ES5 code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to look in base configuration and assumed we used the default, which is ES3. Fixed.

typescript,
compilerOptions: {
allowJs: true,
importHelpers: true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be removed because It's already set in the root tsconfig.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This didn't work for me when it was not included yesterday, but I will try again. Fingers crossed :)

Update: No size impact so I removed it.

@@ -26,6 +26,7 @@
"prepare": "yarn build"
},
"main": "dist/index.node.cjs.js",
"mainES2017": "dist/index.node.esm2017.js",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

main-esm2017 to be consistent with the existing convention? We have a lite-esm2017 target in @firebase/app which is used to produce firebase-performance-standalone.es2017.js

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was looking for a precedent. I am glad there is one :)

@@ -2,6 +2,7 @@
"name": "@firebase/firestore/memory",
"description": "A memory-only build of the Cloud Firestore JS SDK.",
"main": "../dist/index.memory.node.cjs.js",
"mainES2017": "../dist/index.memory.node.esm2017.js",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

main-esm2017?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@schmidt-sebastian schmidt-sebastian changed the title Pre-process all ES3 builds Pre-process all ES5 builds Apr 1, 2020
@schmidt-sebastian schmidt-sebastian removed their assignment Apr 1, 2020
@@ -45,6 +48,11 @@ import {
// The in-memory builds are roughly 130 KB smaller, but throw an exception
// for calls to `enablePersistence()` or `clearPersistence()`.
//
// We use two different rollup pipelines to take advantage of tree shaking,
// which Rollup only supports in pure ES2017 builds. The build pipeline in this
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not accurate. rollup can tree shake ES5 builds as long as they are in the ESM format. The limitation is specific to the Typescript classes compiled down to ES5.

Also do you mean post-tree shaken ES2017 builds? IIUC, treeshaking is done in this phase, the second phase just changes the module format.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the comment. I did mean "pre tree-shaken", as in "these builds are already tree shaken", which is the same as "post tree-shaken". Hence, I dropped the term.

@schmidt-sebastian
Copy link
Contributor Author

I also updated the PR to remove the error handling for memory externs, which was meant to ensure that our ES5 builds don't accidentally pull in sources they don't need. If this happens now, Rollup will just tree shake those files.

@schmidt-sebastian schmidt-sebastian merged commit e062933 into master Apr 1, 2020
@schmidt-sebastian schmidt-sebastian deleted the mrschmidt/splitrollup branch April 6, 2020 19:26
@firebase firebase locked and limited conversation to collaborators May 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants