okta-auth-js
okta-auth-js copied to clipboard
Large bundle size
Is this expected? Any tips on how to obtain a smaller bundle?
Obviously our webpack already does minimizing and optimization. However, okta-auth-js really seems to stand out as a large file in the bundle
@jchabotamica Thanks for posting!
@aarongranick-okta can you help with this?
@jchabotamica Thank you for raising this issue. We are definitely concerned about the bundle size and have identified several ways to reduce it. There was a 3rd party dependency (jsonpath) which was adding about 250K to the auth-js bundle. We have resolved this in auth-js 5.2.0: https://github.com/okta/okta-auth-js/blob/c04f316d1f9f130da76aecd70c2af40ad5c5fd12/CHANGELOG.md#520
However, the current version of the widget is still using version 4.x of auth-js. We are currently working on upgrading the widget, so the bundle size will come down when that is released.
We are also converting auth-js and other Okta dependencies to ES modules which will bring the size down further thanks to tree-shaking.
Thanks @aarongranick-okta ! I'm looking forward to taking advantage of tree shaking. I noticed the okta-signin-widget is even larger! The screenshot I sent is after I did some trial and error of removing the widget. Since this is used 100% of a user's first load of our SPA, it really hurts us performance wise!
I am also using okta-auth-js 5.3.1
@jchabotamica You probably can try the resolve.mainFields config in webpack to tell the bundler to load okta-auth-js ESM bundle from the module field. From the screenshot, looks like it loads the bundle from the 'browser' field.
@aarongranick-okta do we have an idea of when to expect these changes you mentioned above?
@aarongranick-okta +1 on this. Nearly half our bundle size is Okta. Would really appreciate an update on this or any ideas you guys have had since the issue was opened.
@aarongranick-okta I am using 6.1.0 and am still seeing a very large bundle size of 200+ KB:
![Screen Shot 2022-02-10 at 18 05 45](https://user-images.githubusercontent.com/86328788/153517880-b61c225d-5e7a-46ca-b030-101fc5a4c359.png)
The only thing I import from the module is OktaAuth
.
When looking at the project dependencies, I see that pollyfills are included via @babel/runtime-corejs3
package. I'll admit to not knowing much about pollyfilling in general, but it seems like the library should set a minimum browser / node target and let the application itself worry about polyfililng. Documentation can always be provided on which polyfills are needed and how to apply them.
I'm now getting the following warnings and many more like it out of my Angular project. The SDK is imported via the Okta Angular SDK.
Warning: ui\node_modules\@babel\runtime-corejs3\core-js-stable\array\from.js depends on 'core-js-pure/stable/array/from'. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies
Warning: ui\node_modules\@babel\runtime-corejs3\core-js-stable\instance\concat.js depends on 'core-js-pure/stable/instance/concat'. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies
I don't know how much the pollyfills affect the final bundle size, but this seems like a good optimization to make.
@sdiltsDNRC Thanks for the suggestion! We will consider setting a proper target in the next major version.
To handle the warning, you can add @babel/runtime-corejs3
to angular's commonjs allow list to ignore it. As we are still not in a perfect ESM JS world, some commonjs specific config still will be needed for a while.
@aarongranick-okta I am using 6.1.0 and am still seeing a very large bundle size of 200+ KB:
![]()
The only thing I import from the module is
OktaAuth
.
I am on "@okta/okta-signin-widget": "^6.6.1",
and still see the same bloat.
@aarongranick-okta Any updates on reducing the size of the sign in widget? Thanks.
It's still relatively large, but the newly released 7.0.0 is massively better than it was previously. If you use Angular, you are also going to want that release too, as it allows further optimizations with an Ivy build.
I'd say it mostly fixes the problem, but I haven't actually looked at how big the library size is by itself.