Tree shaking #434
Open
Tree shaking #434
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…lineDynamicImports - Added sideEffects: false to package.json - Removed inlineDynamicImports from vite.config.ts - Achieved code splitting with main bundle reduced to ~0.7KB (ES) / ~1.2KB (CJS) - Multiple chunks created for proper tree-shaking
…entry points
- Add tree-shaking entry points for 9 categories: map, layers, sources, controls, animations, geometries, interactions, styles, helpers
- Create vite.treeshaking.config.ts for multi-entry tree-shaking builds
- Update package.json with subpath exports for all categories
- Add build:treeshaking and build:all npm scripts
Bundle sizes achieved:
- helpers: 343B ES / 443B CJS
- controls: 701B ES / 1.3KB CJS
- geometries: 5.0KB ES / 5.2KB CJS
- animations: 6.2KB ES / 6.4KB CJS
- layers: 20.9KB ES / 21.5KB CJS
- interactions: 21.8KB ES / 22.7KB CJS
- sources: 26.1KB ES / 26.6KB CJS
- styles: 43.0KB ES / 43.6KB CJS
- map: 183.7KB ES / 184.1KB CJS
Enables selective imports like:
import { OlMap } from 'vue3-openlayers/map'
import { OlVectorLayer } from 'vue3-openlayers/layers'
- Split UMD build into separate vite.umd.config.ts to avoid esbuild errors - Add emptyOutDir: false to all configs to prevent cleaning between builds - Update build scripts to run in sequence: ES/CJS → UMD → tree-shaking - All three build types now complete successfully without conflicts Builds generated: - vue3-openlayers.es.js (687B) - ES module - vue3-openlayers.cjs.js (1.2KB) - CommonJS - vue3-openlayers.umd.js (1.6MB) - UMD bundle - Category tree-shaking bundles (343B-184KB each) This resolves the previous esbuild syntax errors in UMD format.
- Add rollup-plugin-visualizer dependency for bundle analysis - Create build:analyze scripts that set VITE_ANALYZE=true - Conditionally include visualizer plugin when VITE_ANALYZE is set - Generate separate stats files for main build and tree-shaking builds Scripts added: - npm run build:analyze - Analyze main ES/CJS build - npm run build:analyze:treeshaking - Analyze tree-shaking builds - npm run build:analyze:all - Analyze both main and tree-shaking builds Outputs: - dist/stats.html - Main build visualization - dist/stats-treeshaking.html - Tree-shaking build visualization Both files show interactive bundle size analysis with gzip/brotli compression stats.
…e-shaking - Add providers-entry.ts for OpenLayers utilities and providers - Add composables-entry.ts for Vue composables - Update vite.treeshaking.config.ts with new entry points - Update package.json exports with subpath exports for new categories New tree-shaking bundles: - providers: 788B ES / 1.9KB CJS - OpenLayers utilities, format, geom, etc. - composables: 700B ES / 1.2KB CJS - Vue composables for layer, source, etc. Complete Phase 2 categories (11 total): ✅ map, layers, sources, controls, animations, geometries, interactions, styles, helpers, providers, composables This completes the comprehensive Phase 2 granular tree-shaking implementation.
✅ Deploy Preview for vue3openlayers ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Great job! I like it so far but since the refactoring introduces breaking changes, can you provide a detailled mirgation guide for the changelog? |
|
Good thing is, almost nothing particularly breaking, other than changing the component names in markup where needed. Since I'm still in progress, I will leave the changelog for the last step. Also, I'm working strictly on manual imports since on our side we do not use plugin itself, someone else will need to verify (and perhaps adjust) tree shaking for that use case. The worst that can happen is really no tree shaking for plugin usage yet (and obviously differences in component names consumers will need to fix). |
|
@d-koppenhagen looks like I'm done for now, would be great to review and perhaps release. Not sure if you want a preview version or not, seems to be working okay with my app, one migrated fully to a treeshaken library, one still using the old "namespace" imports. I'm not sure what's up with playwright here, but seems perfectly fine locally: 
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
As mentioned in #378, the full library size is astronomical, especially if you just have some small components to use to view some basic map data. This PR intends to solve the issue by making the library tree-shakable.
How Has This Been Tested?
I've been testing the changes using yalc (local package store for npm/yarn), results in screenshots. The bundle size drops substantially. Keep in mind I have a separate bundle for both openlayers and vue3-openlayers packages in there.
I have not run the tests yet as I'm still in progress of making it better, reexporting the categories for example so you don't need to flood your import section with a bunch of default imports. All in all, it seems to be working fine as is mostly backwards compatible, except capitalization issues for fixed component names (it's best to follow OL capitalization IMO).
Screenshots (if appropriate):
Today's result, importing the "namespaced" components, even if you only use a few of them:
After using the explicit, tree-shaken imports:
Types of Changes
Checklist:
If you added a new component feature (layer, geom, source, etc.), please be sure to update the documentation:
output.globalsinvite.config.tstestdirectory)src/demos/<Component>Demo.vuedocs/componentsguide/<Category>/<Feature>/index.mdcontaining the Demo and documentation for the componentdocs/.vitepress/config.ts