You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All of these sizes are important criteria when choosing a library, and they will be stored in the .size-snapshot.json file.
There is also a nice feature for the es output format which provides sizes of treeshaked bundles with both rollup and webpack, so if your library has more than one independent parts, you can track that users will not consume dead code. Such bundles entry point looks like this
// nothing is imported here so nothing should go in user bundleimport{}from"library";
Why bundle with rollup
internals are hidden so you shouldn't worry that user reuses your frequently updated modules
faster user bundling if library has a lot of modules
predictable and more efficient scope hoisting and as a result more predictable size
easier to work without sourcemaps with vendors since development bundlers add a lot of unreadable stuff in module definition
If you use uglify or terser plugins, then make sure they are placed after this one.
import{uglify}from"rollup-plugin-uglify";// or import { terser } from "rollup-plugin-terser";import{sizeSnapshot}from"rollup-plugin-size-snapshot";exportdefault{// ...plugins: [sizeSnapshot(),uglify({toplevel: true})],};
Options
snapshotPath
type: string
default: '.size-snapshot.json'
matchSnapshot
This option allows you to verify that contributors don't forget to build or commit the .size-snapshot.json file. If this is true, the plugin will validate the snapshot against an existing one. Typically, one would define this option's value as true during continuous integration; using it locally is unintended.
type: boolean
default: false
threshold
Possible difference between sizes in actual snapshot and generated one.