Because this SDK is essential to being able to effectively use Auth0 with single page apps, a core goal of the library itself should be small package size.
Using this tool we see that the resulting minified + gzipped package comes in at around 28.7kB
https://cost-of-modules.herokuapp.com/[email protected]
I wanted to open this issue as a starting point for a discussion to help drive this down, and ask if you would be open to receiving PR's that would change the underlying dependencies in favor of smaller packages or hand-rolled solutions.
It'll be smaller in a few weeks, once we start using only the OIDC conformant flow (which means we'll remove all the non-OIDC stuff from the code). But I'm open to ideas. Please discuss the ideas first, before starting a PR so we can be in the same page and you don't end up wasting some time to create a PR that we'll never accept it. Thanks for the interest!
And also, what an amazing tool! Never heard of it until now.
Cool! Is the OIDC code already in the latest released version? Is there perhaps a way to import only the OIDC code directly instead of using the top-level import?
Also I think the main bloat of the package comes from superagent which could be swapped out for a more lightweight request client like axios
No.. We're still using ES5, so we don't export modules. Moving forward, we'll make the code work with tree shaking, but we need to migrate to ES modules and do the proper exports first. This effort will start after we release the new major version (when we drop non-OIDC stuff), which has no ETA yet.
Sorry, you didn't really resolve the issue. Would you mind re-opening?
Also are you open to PRs replacing the superagent with axios?
What's the size difference?
When comparing min+gzip:
Actually, axios is not 1.0 yet. We're not willing to take a dependency on it until it reaches a stable version which we can actually rely on. But, by the time, who knows.. maybe we just ditch everything and use fetch instead 馃槤
To be entirely honest, the bundle size is good enough for us and we're more concerned about Lock's bundle size, which is really big.
I would have suggested fetch too, but it lacks support for canceling requests mid-flight. Which is something you rely on, from the looks of your current request builder anyway.
No worries, the smaller bundle size is a nice to have for us at the moment. If we need to, we might just re-implement the calls with your url builders :)
Thanks for the feedback though.
In addition to being less compact, superagent depends on node-formidable, an npm package that's only been spottily maintained for the past 3 or 4 years, and which relies on some outdated tricks (e.g. redefining require for testing purposes) that one must work around if bundling with, for instance, rollup and babel.
I've spent the past day and a half trying to work around idiosyncrasies in auth0 v8 to get it to work in an isomorphic React application, but am about ready to give up, focus on other priorities, and hope the auth0 team works out the kinks before auth is the last remaining thing on my to-do list in the current project I'm working on.
What is not working with server side rendering?
@luisrudge
Relevant details:
Scenarios:
SyntaxError: path/to/auth.js: Unexpected token
export default class Auth {
auth0 = ...
^
I've tried a number of babel + rollup configurations to get this working, but haven't stumbled upon the correct combination, yet, and would prefer not to have to enable es6 class support in my application just for Auth0.
Warning: 'default' is not exported by 'node_modules/buffer-es6/index.js'
1: import * as index from "node_modules/buffer-es6/index.js"; export default ( index && index['default'] ) || index;
^
Warning: 'default' is not exported by 'node_modules/rollup-plugin-node-builtins/src/es6/string-decoder.js'
1: import * as stringDecoder from "node_modules/rollup-plugin-node-builtins/src/es6/string-decoder.js"; export default ( stringDecoder && stringDecoder['default'] ) || stringDecoder;
Otherwise, the errors on the server go away, but the browser application breaks with the following error:
Uncaught ReferenceError: process is not defined
at node.js:34
at createCommonjsModule (bundle.js:13)
at empty.js:1
at client.js:54
In scenario 2, the server-side warnings and Uncaught ReferenceError on the browser only occur when I import auth.js into another module that is executed. If I don't import it, the warnings on the server and error on the client disappear.
Hmm.. not sure where are you getting this from.. We don't use ES6 in auth0.js and this snippet of code is not from auth0.js:
Nevermind the above, I misread it.
As stated in the quickstarts, the samples are created with create-react-app (thus with webpack). I'm not sure what config you have and why your bundling is failing, but it's certainly not an issue with auth0.js. It's a bundling issue.
The project has no bundling issues until I pull auth0 in. So while it's a bundling issue, it certainly seems related to auth0, since the issue disappears as soon as I remove auth0 from the project.
I'm using rollup + babel, as I mentioned above.
Please create a new issue with a repro project and I'll try to help. Keep in mind the instructions in the quickstart are compatible with create-react-app and webpack, You might need to adapt those instructions to make it work with rollup.
Most helpful comment
In addition to being less compact, superagent depends on node-formidable, an npm package that's only been spottily maintained for the past 3 or 4 years, and which relies on some outdated tricks (e.g. redefining
requirefor testing purposes) that one must work around if bundling with, for instance, rollup and babel.I've spent the past day and a half trying to work around idiosyncrasies in auth0 v8 to get it to work in an isomorphic React application, but am about ready to give up, focus on other priorities, and hope the auth0 team works out the kinks before auth is the last remaining thing on my to-do list in the current project I'm working on.