Bundle ESM for Vue 3 prod

[porfirioribeiro]

What problem is this solving

I'm trying to use pinia in a microfrontends architecture, and we are planing to use importmaps to solve duplication of bundling dependencies.
So we're mapping pinia to https://cdn.jsdelivr.net/npm/pinia/dist/pinia.esm-browser.js

But it comes with some issues.

• Pinia imports vue-demi, i think it's great that pinia support both Vue 2 and 3, but this hurts the esm imports as i will need to add an import map for vue-demi also
• It also imports @vue/devtools-api, which is great in development, but could probably be avoided in prod

I have a working example https://jsfiddle.net/porfirio/qh8pf5xb/22/

Proposed solution

Have a new bundle without vue-demi and pointing directly for vue (3)
Probably create 2 bundles, one for prod without devtools, other for dev.

The pinia-esm-vue3 bundle, should only have the dependency on vue

Describe alternatives you've considered

It is possible to make it work, as-is, but it brings a lot of configuration that needs to be added

[posva]

This is interesting, I wouldn't use the native ESM for anything else than playing around but apparently, there are use cases. Do you have a demo with Vue Router as well? I remember people were struggling to get that working: vuejs/router#694

As for vue-demi, I don't think it will be adapted for the prod version as technically one could be using this in Vue 2

[porfirioribeiro]

I added vue-router to the jsfiddle, they also use @vue/devrools-api but not vue-demi

ESM should replace UMD, as the default option for sharing libraries, in my opinion.

In my use case, we have different product teams developing “blocks” that can be used to create a page.
Those blocks are bundled and deployed independently. In the past, while using Vue2, we used to have a global UMD vue script on the page and every product would not bundle vue and alias it to the window.Vue.

But it gets harder to manage, and it's harder to use UMD when you want your bundles to be ESM, so you can leverage native dynamic imports, import.meta, etc.

We started by keeping Vue 3 externalized by replacing at build type 'vue' with the url for the vue browser bundle.
But then we'll have to bundle in every product the dependencies, like pinia.
Since importmaps are now supported in evergreen browsers and there's a polyfil for browser who does not support, we are working on using them to allow sharing of the major and bigger dependencies, that every product needs. Likr pinia.

[posva]

Thanks for the feedback, it's useful!

ESM should replace UMD, as the default option for sharing libraries, in my opinion.

That would be great but it's still not possible due to Safari

[lmiller1990]

Wait, is ESM not working in Safari? What's the Safari blocker?

[posva]

Import maps

[porfirioribeiro]

They are supported on all evergreen browsers https://caniuse.com/import-maps

And there is a polyfill that works for most of other browsers, giving a very high browser support

[lmiller1990]

Ah, I knew Safari had it, but it looks like it only just landed. Still, it looks like the technical blockers are gone.

[Tragio]

Hi @posva 👋

Since all browsers are at 91% globally supported and there are polyfills. How do you see this feature request going further? Is there any way we can help you implement this?

Thank you very much and thank you @porfirioribeiro for the amazing feature request and detailing. 🚀

[posva]

@Tragio Nothing has changed since Jun 14. Safari 16 (2023) still misses this feature.
That being said, if anybody wants to submit the PR I should be able to review it in the following months.
Although I still only use native ESM for dev only and playgrounds. I wouldn't recommend using pinia or vue-router esm in production Vue applications because of the overhead they bring due to the lack of tree shaking (even after removing vue-devtools)

[validide]

@posva I am running into a similar issue but for my current scenario I think publishing a pinia.prod.mjs version, without the DEV TOOLS would be sufficient.

Would it be ok to change the rollup configuration to also publish that one and create a pull request?

[backrunner]

@posva I am running into a similar issue but for my current scenario I think publishing a pinia.prod.mjs version, without the DEV TOOLS would be sufficient.

Would it be ok to change the rollup configuration to also publish that one and create a pull request?

Agree with this idea, I'm running into an issue about bundle size today which has been discussed in #1593, as for Webpack 4, the tree-shaking won't work as expect, it will bring another 20KB garbage into the chunk, even if I replaced USE_DEVTOOLS variable with expression. The only way to remove the devtools related lines is creating a special variation for production.
It will be way more convienient if there's a dist file for production only, I can simply setup an alias to solve the issue:

{
  resolve: {
    alias: {
      'pinia$': path.resolve(__dirname, './node_modules/pinia/dist/pinia.prod.mjs')
    }
}