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

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.

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

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

Import maps

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

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

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. 🚀

@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)

@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?

@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')
    }
}

@porfirioribeiro - did you find a workaround for this? I'm having a similar situation. A small and simple pure JS app that currently uses just ESM Vue 3, but I would like to use pinia. I was hoping to not have to employ npm etc and add a build step which I've currently been able to avoid

Unfortunately, no @thomthom

I was hoping that pinia 3 would have this solved, but there is still no build for browser without dev-tools
https://cdn.jsdelivr.net/npm/pinia@3.0.0/dist/

At least vue-demi is gone, maybe @posva will have the chance to address this in a next minor version.

I also use Vue.js and Pinia with ESM and importmap. I have the same problem with @vue/devtools-api

Uncaught TypeError: Failed to resolve module specifier "@vue/devtools-api".

Importmap:

 <script type="importmap">
      {
          "imports": {
              "vue": "/node_modules/vue/dist/vue.esm-browser.js",
              "pinia": "/node_modules/pinia/dist/pinia.esm-browser.js",
          }
      }
  </script>