Bundles that excludes polyfills, and es2015+ target

Describe the problem you’d like to have solved

In our app we are currently only targeting modern browsers, and I noticed that this library is bundling a lot of code that is only necessary for older browsers. The largest part of this size comes from polyfills. When reading up on polyfills, I’ve often came across the recommendation that polyfills are for apps, not for libraries. This recommendation exists because an app may already include similar polyfills. Polyfills included by libraries will then become dead code. The included polyfills are roughly 35kb in total at this moment, which is quite a lot.

Another source of of extra code comes from code that is transpiled to es5. I did a small test to see size changes from various changes. Dropping polyfills had the largest impact. But keeping spread/rest (es2018), arrow functions (es2015) and classes (es2015) also had large impact (see below).

auth0-spa-js.production.esm.js bundle	Size	Diff (from previous)	Total diff
master (es5)	101kb	-	-
master -polyfills (es5)	65kb	-36kb	-36kb
master -polyfills + es2015	56kb	-9kb	-45kb
master -polyfills + es2017	54kb	-2kb	-47kb
master -polyfills + es2018	37kb	-17kb	-64kb

• Differential loading (as described in your blogpost) can take advantage of es2015+ code instead for modern browsers

Describe the ideal solution

Ideally, I think polyfills should be dropped from all bundles (except maybe UMD), and a @auth0/auth0-spa-js/polyfills entrypoint can be created that can be imported to get the same functionality as before for those who want to opt-in to the polyfills. This is a breaking change though, and could be delayed for a v2.

Even if the above is skipped, I think it would be great to create a new bundle that uses either es2015, or ideally for us, es2018. Angular uses the package.json key esm2015 for their “modern”/differential bundles, which could be adopted, but is not strictly necessary. As long as there exists a bundle with code that is not transpiled, it should be possible to configure Webpack/Rollup to use another entrypoint for this package.

Alternatives and current work-arounds

• Creating your own package that builds from source but removes/stubs polyfills. A bit painful to maintain.
• Configure Webpack/Rollup to use the src folder instead (similar objections as the above)
• Taking the ~36-64kb size hit to our app, which is a bit troubling when caring about performance

Additional context

The web is getting more and more concerned with faster content, smallar bundles, lazy loading, and other techniques to avoid loading large monoliths at once. 101kb is around half of recommended budgets for JS on a page, at least if various posts on https://web.dev is to be believed 😉.

[divmgl]

Is this something that the community would be able to contribute to?

This is an Auth0 maintained package for a service they provide. It’s been two years now. Needless to say, we should have seen some movement here.

Edit: I went ahead and just removed the polyfills myself. https://github.com/divmgl/auth0-spa-js https://github.com/divmgl/auth0-react

The rendered size of the bundles goes from 148kb to 92kb. It’s about a ~50kb reduction, which is better, but Auth0 is still one of the largest packages in my bundle. Just for React Hooks, JWT tokens and redirects to a sign-in page.

I’m being facetious; I’m sure there’s more complexity that I’m not accounting for, but it’s still disappointing.

[frederikprijck]

For those interested, we have merged a PR to drop the polyfills a couple of weeks ago: https://github.com/auth0/auth0-spa-js/pull/951 as well as update the output target https://github.com/auth0/auth0-spa-js/pull/953, this will be released as part of our v2, which is expected to be released in beta in a week or two from now.