Remove webpack and add Rollup as a module bundler#772
Conversation
luisrudge
force-pushed
the
feature-rollup-bundler
branch
from
4b98683 to
6035e67
Compare
luisrudge
force-pushed
the
feature-rollup-bundler
branch
from
6035e67 to
c26c61b
Compare
|
@luisrudge - Thank you for the detailed run-down! Informative screenshots and good supporting article:
I'm definitely sold that this is the right way to go and I don't know how helpful an in-depth config file review would be. My main concern here, though, is what we talked about last week: the change from In short: is there a case where changing this output folder will cause a break in someone's deployment procedure, even if it's in the minority of cases? Edit: one more that came up from the article ... is there any reason to include a |
| name: 'auth0', | ||
| file: 'dist/auth0.js', | ||
| format: 'umd', | ||
| sourcemap: isProduction ? false : 'inline', |
There was a problem hiding this comment.
Why are we checking isProduction if these are dev files?
There was a problem hiding this comment.
isProduction is more like: areWeBuildingAProductionFile
| commonjs(), | ||
| json(), | ||
| replace({ | ||
| __DEV__: isProduction ? 'false' : 'true', |
There was a problem hiding this comment.
Not sure what that means 😬
There was a problem hiding this comment.
Simpler statement, same meaning
There was a problem hiding this comment.
nope, I need the result to be a string, so it'd have to be either (!isProduction).toString() or what I have there
rollup.config.js
Outdated
| input: 'plugins/cordova/index.js', | ||
| output: { | ||
| name: 'CordovaAuth0Plugin', | ||
| file: 'dist/cordova-auth0-plugin.min.js', |
There was a problem hiding this comment.
Might be better to have dist/ as a var
Yeah, I'll change to use build and dist.
|
luisrudge
force-pushed
the
feature-rollup-bundler
branch
from
f009951 to
9c1e2bd
Compare
In the same approach as auth0/auth0.js#772 and auth0/auth0.js#774, this PR modernizes our build system. - Uses https://github.com/developit/microbundle to build the project. This has the benefit of building every type of module (cjs, esm, umd) in one go with 0 config - Migrate to ES Modules (we need this to proper implement three shaking) - Migrate tests to ES Modules as well - Fix telemetry file generation - Fix docs files generation - Prettify code in a precommit hook - Check for ES5 compatible code to make sure we don't ship unsupported javascript syntax - Print bundle size
2 participants
Rollup is better suited to do module bundling for libraries. One of the reasons is because it allows us to easily target different types of bundles like UMD, ES and CJS. This PR only maintains the UMD bundle for now, but we can add ES modules later. The benefit of using ES modules later is that consumers of this library will be able to do "tree shaking", which means their bundle will only include what they use, everything else will be left off. This can greatly reduce the bundle size for people only using
WebAuthand notAuthentication, for example.Here's a great article about the difference between webpack and rollup for libraries:
https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c
Summary of changes:
distandbuildfolderdistfolder instead ofbuildbrowserfield in package.json which specifies alternative files to load for people bundling for the browserfilesfield in package.json so we deploy the distribution files to the npm registry (it will allow users to use services like https://unpkg.com/)Before
After