Fishy dev build for npm:vue@3.2.47

[Bubblyworld]

If you run await import("https://jspm.dev/npm:vue@3.2.47") in the console, it throws:

Uncaught SyntaxError: The requested module '../../npm:@vue/runtime-dom@3.2.47' does not provide an export named 'default' (at e8b1ebe6.js:5:8)

Looking at that rollup chunk, it's trying to import the missing default:

import runtimeDom_3_2_47__default from '../../npm:@vue/runtime-dom@3.2.47';

...but indeed, runtime-dom has no default exports. Unsure why this is happening yet.

[guybedford]

Can you post a failing test case for this to babel-plugin-transform-cjs-dew?

[Bubblyworld]

Ah, turns out this is actually a conventions problem, not a dew issue. Vue's package.json has a "modules" field pointing to "vue.runtime.esm-bundler.js", which is supposed to only be used server-side as part of their build tools (see here). It's not pointing to an ESM build of the package, which is what the CDN expects. I'll add an override.

[Bubblyworld]

(I guess we should still link to vue.runtime.esm-bundler.js, but not for browser environments)

[Bubblyworld]

Hmm, this seems to be a problem with a whole bunch of the @vue packages... both @vue/shared and @vue/reactivity have exports with "modules" pointing to a server-side-only build, for instance.

[Bubblyworld]

Oops, this shouldn't have been closed.

[Bubblyworld]

The plan to solve this is to deprecate "module" as a default condition in the generator (and related projects), since packages don't consistently use it to mean "this is an ESM build of the package". For instance, in vue the "modules" field points to the node backend (which happens to be ESM) and not an ESM build of the main entry point.

[blangenfeld]

Closing #274 in favor of this one.

[guybedford]

@blangenfeld did turning off the module condition resolve this issue for you in #274? Specifically running with jspm --env no-module?

[guybedford]

Investigating this further in jspm/overrides#16, the exact issue is that the esm-bundler builds of Vue assume the process global to do dev / production branching, whereas JSPM does not support this in an ES module context (only for CommonJS for legacy support).

Therefore, as a compat issue, I've landed the override created by @tonysm in jspm/overrides#16 including fixes for @vue/reactivity, @vue/shared and @vue/runtime-dom.

If there are other Vue packages that we have missed though, we should add overrides for those as well, so please do report here if there are further issues.

[tonysm]

@guybedford is the override already working? I still see the "process is not defined" when importing Alpine's ESM. Here's the sandbox link: https://jspm.org/sandbox#H4sIAAAAAAAAA6VUXU/bMBR951dcvBeYmmSFbZpKUgEa4kO0mhZVE49uctu4JLZnO+3Sif8+x25YqcaGxkOb+PrmnON7j2+8n4vMNBKhMFU53Iu7B9J8uAcQV2goZAVVGk1CajMLPhG3YZgpcTjh7pnHkV8/fsJphQlZMlxJoQyBTHCD3EKsWG6KJMclyzBwix4wzgyjZaAzWmLStwRx5BXEU5E3DnU/COwD4Cb9MoJL5KioEQquqxYfRlS63YucGZh8vR3Y8xipB1E071LDhZZVyET0ZnI0Xtxdnt9/Hr1TTbq+SSf9Ih2tZDP6cbtO5dFofLcej6/X52dny+8Ldnk1P7PgQdDqgFhnikkDbdESwhx9RaUryk+nYRPUZLAJ2BAtJeO4aGPkURl9lMRlNehSTo/D/lHYj3KmTVSJvC4xRF3ZXOLQHnqeRWdC4hOSPwBvbduE02WNkUKaGbZkpvmLmJ3MVlP43kv6HW1lBdOa5yW21SW9HSZtbYP5v1h81jaDj+yib8Af9rr/9hdHvh1t9TcugYsURq5skBas0oPOI7ZLGqQomxkrS5hZ8/jqapgqsdKoNKyYKURtgG19oWvpFgcpnVHFoP8xPD7cuKEzA9UNz0CrLHnuqKgDzxboVtRpP/zQ9Xhnqz0rZEpoLRSbM54QygVvKlFrMtw9b8n4PSgsE+IhpH0XNCdQKJw9K+a/uhsNX0n40ka/hugFlyjqavfkIvscd4uha/9b21foEGGmRLV1kU88CkAUwTfFDFq3ML6xlB13uR2pqLAH1mctDGiU1A4iBGs/dE6zQWI9Q4Aao9i0tnuCgymwQ/EKQ0djB6gW9hSlmB90Ig5PnlyBOPLT0g5PN8V/ATqREpndBQAA

[tonysm]

Interesting, I see the correct files in the generator when pulling @vue/reactivity and @vue/shared directly (generator link), but when it comes as a dependency of Alpine, it still pulls the bundle ones (generator link).

[guybedford]

@tonysm AlpineJS seems to be using version 3.1.4 not 3.3.4. I've also invalidated that version as well now.

[tonysm]

Hey, thanks for the help on this @guybedford. It's working now!