UMD support

[joebnb]

What problem does this feature solve?

no one think umd is better than directly declare a variable in window? for compatibility

vue 2 did this ,it is ok for most integration,is vue3 and vite was maintained by same team ? i think the design and code quality is goes down or some thing (techincal point) i miss understand casue my faulty view.

the vite old design and new issue
vitejs/vite#7948

vitejs/vite#10822

and vue3 dist

What does the proposed API look like?

UMD support pls

[LinusBorg]

I have trouble understand what supposed problem a UMD build would solve. I also don'T see the connection with the linked issues.

• Both a UMD and a IIFE build (our vue.global.js) will add a global variable called Vue when directly included via a <script> element i.e. from a CDN. Both won't add any other global variables.
• a UMD build would also behave like a CommonJS file in a bundler-environment, but for that, tools like Vite would instead include the ESM build. Todays build tooling prefers ESM over CommonJS.

I I had to guess, your problem might be that you include the ESM build as a plain, non-module <script> in the browser, which would simply be a mistake.

[LinusBorg]

If you hav an actual bug to report, please do so in an issue with a bug report with a runnable reproduction

[joebnb]

the way to solve the issue => close.

• HOW many npmpkgs now support esm bundle?
  * if majority not why not choice a sleek upgrade plan to step by step change it
• if vue use esm bundle use '.mjs' extention as a common principle

did UMD format bad as VAR VUE = XXXX

im not use it in a commonjs environment and i tested react、angular it's all works fine，but vue have problem and rise issue -> close twice.

so as a system designer in opensource, you think “we need teach our user how to use our product？”. and following the same pattern product same page is the goal?

or UMD is a big work of change？

i think neither. arrogant is.

[LinusBorg]

You did not raise an issue, you opened a feature request - for a feature that i don't see necessary. If you rather think you have a bug, you should follow the issue guidelines and open an issue with a runnable reproduction.

I still don't really have any idea what the problem is that you are trying to describe. a runnable reproduction could clear that up.

[joebnb]

If you hav an actual bug to report, please do so in an issue with a bug report with a runnable reproduction

in this issue i talk about 2 issue one is vue umd support，one is vite bundle of pollution global (and this have a link).

if the issue would be fix,just fix.in this case,i can switch to react and i can make a work around .

i'm not start project now,because the bundle formate problem,for me not have nessary to fix it .so let them exist,it's NOT my project,i think i'm a contributor of this,im not begger.current was tired of write issue about vue and vite

vitejs/vite#10822 (comment) other guys jump in and understand what im point,but vite need a reproduction to reproduce. and i was make a work around.

thats fine, if i use edit this comment estimated time it have already work around.

[LinusBorg]

Bug reports require runnable reproductions. even us core contributors do follow that rule when we open issues ourselves. We ask the same from other people reporting problems. Runnable reproductions are required for us to be able to understand a problem clearly.

Now a few points, trying to explain my problems of understanding you.

• You first link to fix: inject esbuild helpers in IIFE and UMD wrappers vitejs/vite#7948 but this is a fixed issue in vite that affected IIFE as well as UMD, so I hav eno idea how this is relevant to your request.
• Then you point to multiple vite bundle import in one page throw:Uncaught SyntaxError: Identifier 'React' has already been declared  vitejs/vite#10822 which is about a problem with react, with one guy simply stating "I have this problem with Nuxt" - no reproduction.
• Finally in that same issue, you link to a previous bug report in this vue repository (vue bundle problem of use in require js like common js module #7206), where again, you did not provide a runnable reproduction to understand in what circumstance you seem to have a problem with your IIFE and CommonJS builds.

Now we have another issue open, again with zero code to check out, and after all of these Issues I'm sorry to say I still don't understand the problem. Code would help. You don't want to provide code. So we will keep this issue closed.

i'm not start project now,because the bundle formate problem,for me not have nessary to fix it .so let them exist,it's NOT my project,i think i'm a contributor of this,im not begger.

Everyone is required to provide runnable reproductions in bug reports, even core contributors (i.e. #7319). Us asking for a runnable reproduction of a problem is not us making you beg. It's us asking for minimal standards in order to be able to understand the problem.

[joebnb]

ok ok,we need a runnable reproductions to debug it,screen shot or logs not enough,leave it and have a good day.

[LinusBorg]

screen shot or logs not enough

Yes. Not enough. Good day to you to.

[yyx990803]

vite 或者是任何现代打包工具打包 Vue 3 都会默认引用 esm 格式，不存在全局变量污染。而 global 格式顾名思义就是暴露全局变量用的。

你的问题到底是什么，你并没有解释清楚。你自己觉得 umd 是唯一解决你问题的答案，我们觉得未必。你是不得不用一个不能处理 esm 的打包工具呢，还是错误的引用了 global 包呢，还是什么其他情况，你不提供重现，我们怎么可能知道？

另外，一个建议：调整下心态，加强一下沟通能力，好好说话。开源维护者不欠你任何东西，你如果不能心平气和的沟通，那我们也不会有兴趣解决你的问题，最终吃亏的是你自己。

[joebnb]

算了我删了，不想事多，都解决了没必要浪费彼此的时间和精力，这几个issue从时间线上已经足够说明很多

[joebnb]

早上一来看到这么多人点赞，细细一看，原来是家人们，那我把之前想说的也发上来。

========

1. 我已经绕开这个问题自己搞完了，发这个 issue 只是觉得这个东西应该你们改，你们改更合适，改了能让大家都变好，已经说过了，我是拿自己当contributor 来提这个事情。你们有没有兴趣去解决这个问题跟我没什么关系，没有什么吃亏的，心态不要觉得别人总在求自己，我一般写 web 界面90%都用 react
   

2. 从最开始的 issue multiple vite bundle import in one page throw:Uncaught SyntaxError: Identifier 'React' has already been declared  vitejs/vite#10822 讲为什么我觉得不 ok 了

   • 构建产物的依赖不闭包直接放在 window 上真的合适吗？vite 构建的 bundle 引入了相同的框架库时在页面中有且只有一个，这些bundle是不是受自己控制，依赖的版本是否相容都没法解决，不存在全局变量污染这样单结论是不是给单太简单了？ multiple vite bundle import in one page throw:Uncaught SyntaxError: Identifier 'React' has already been declared  vitejs/vite#10822 (comment) 我觉得这里去掉第一行的 iife 里面一堆的 var 已经可以说明问题了
   • https://unpkg.com/browse/vue@3.2.45/dist/vue.runtime.global.js 这里只看2行，第一行和最后一行，这么写和实现一个 UMD 哪个更优雅呢？

3. 我的问题也说的很明确 umd support，在另外的issue里也说过，我就不多说了，但是为什么在觉得自己会有更好的方案认为我的要求是不合理的，从上面两个问题我并不能看出来有这个势头。

4. 家人们不欠你任何东西，别说家人们了，就是别人都会说，免费的你给你用都不错了还想要什么自行车就你p事多。没有问题，毕竟尤大都这么说了，是呀，开源社区都是免费的，就是今天 vue 直接删了那都跟我没关系，还不能谴责，要放平心态（开源真的免费吗？这个问题值得思考）我们换位思考下，一个 issue 提了一个多月被关掉，当家人们觉得我说话不好的时候，有没有想过，你们说话的方式？好心给路人给一块蛋糕，当着面丢进垃圾桶

[meteorlxy]

我的问题也说的很明确 umd support，在另外的issue里也说过，我就不多说了

这个大概是最大的分歧点了，你觉得你已经讲清楚了，但是读的人可能并没能看懂……你提到的其他 issue 结合起来看也没有帮助我们准确理解到问题所在。

I have trouble understand what supposed problem a UMD build would solve

LinusBorg 回复的第一句就很能说明问题。

我是拿自己当contributor 来提这个事情

通篇读下来没有感受到“把自己当 contributor”，而是包含了很多反问和嘲讽性的语言。上面说的 “调整下心态，加强一下沟通能力，好好说话” 其实就是希望你不要用反问和嘲讽来讨论问题，仅此而已。你上面的回复明显是把这句建议本身也当作了嘲讽，然后开始用更加激进的语言回应了。

然而，你回复越冲，越不利于讨论和理解问题，恶性循环呀。不要带上主观恶意，冷静一下，好好讨论问题。

[yyx990803]

vitejs/vite#10822 的问题是你没搞明白 Vite 的输出产物格式。vite build 的默认输出是 esm，需要用 <script type="module"> 引入。你没有用 Vite 生成的 HTML 而是自己去掉了文件 hash 引入，但用的是普通的 <script> 而不是 esm script，所以才导致全局污染。这不是 bug，而是用法不对。

另一方面，这跟 Vue 是否提供 UMD 根本是不相干的问题，Vue 的 global build 就是专门用于非 ESM 的普通 <script> 场景的，暴露全局变量就是这个 build 的目的。你要打包就应该用 es modules 语法引入 esm build。这里有具体的解释。现代构建工具全部支持 esm，所以我们不觉得有提供 umd 的必要。

你想要 umd support，你得解释清楚为什么一定要有 umd support。#7206 这里模糊的提到你的使用场景，但是信息完全不够。可能是你用的打包工具很特殊，不支持 esm，也可能是你在应该用 import 的场景下用了 require()，也可能是因为你还在用你在 vite 那个 issue 里用的错误用法，那么我们需要知道到底是什么情况，所以才会要求给重现。

直白点说，你对整个问题的理解从一开始就是错的，还把不相干的问题混到了一起，表达能力欠缺，态度上又咄咄逼人，我们能这样跟你说话已经很给面子了。

本 issue 下 Linus 的第一个回复很合理，完全没有任何问题。而你自己看一下你的第一个回复，各种反问，暗讽，说我们傲慢，如果你觉得你的沟通没有问题，我们可以 block 你，因为我们不欢迎你这样的用户。

[joebnb]

另一方面，这跟 Vue 是否提供 UMD 根本是不相干的问题

之前就说过了，这是2个问题，既然是两个问题，所以就是不相干的问题，还要下面再给解释一番，然后说表达能力欠缺？

Vue 的 global build 就是专门用于非 ESM 的普通 <script> 场景的，暴露全局变量就是这个 build 的目的

这不是忽略了最开始的问题给答案么？而且前提是假想出我没有必要用到 umd ，我在上面的问题是：UMD 和直接这么整（用一个空对象把exports的路堵死）有什么区别？这样扩展性就更好了？

你想要 umd support，你得解释清楚为什么一定要有 umd support。

不想要了，不想复读——我在上面的问题是：UMD 和直接这么整有什么区别？这样扩展性就更好了？

直白点说，你对整个问题的理解从一开始就

那么是谁在咄咄逼人，让社区里大家看吧

你自己看一下你的回复，各种反问，暗讽，说我们傲慢

我这个回复，以及最开始贴出来的issue单，看看什么时候的，我那个时候有没有这么说话，为什么有这么多反问，暗讽，还说你们傲慢，此时此刻难道不是吗？

这张图时间是 11月7号 的

请把我 block 掉吧

shame

[Justineo]

no one think umd is better than directly declare a variable in window?

全篇第一句话就是一句反问，还全然不觉得这种语气有问题。

我们来捋一捋这个 issue 的火药味是怎么来的。

如果我没有理解错，Evan 上面的回复帮你捋清楚了你的实际需求实际上并不需要 Vue 提供 UMD bundle 来解决，而是由于你错误地在 <script> 中（而不是 <script type="module">）直接引入了 Vite 打包输出的 ESM bundle，并误认为这是 Vite 的 bug。后来自己给 ESM 包上 UMD wrapper 以后认为“修复”了，并认为 Vue 也应该提供 UMD bundle，理所应当地以“难道没有人认为……”开头，并引用了你给 Vite 开的 issue（没有 repro）。

Linus 看了你的 issue，并没有看出 UMD bundle 和你给 Vite 提的 issue 之间有什么关系，而且也给出了判断：你的问题可能是因为用普通 script 引入了 ESM bundle，而不是有真正的 UMD bundle 的需求，进而关闭了 issue。现在看来，这个判断大概率也是对的。

于是你开始嘲讽：解决问题的方式就是关闭 issue，并指责 Linus 傲慢。

后面 Evan 介入，指出你的沟通方式不妥，但你并不接受，认为自己遇到的问题已经“自行解决”了（并没有，而是在错误的用法上打补丁），而且是自己好心给 Vue 提出了解决问题的方案，但并没有重新审视这个问题技术上究竟是什么原因产生的，对于自己的场景提出 UMD 支持是不是实际是一个伪需求。

自始至终你似乎都无视了 Linus 和 Evan 给你分析的，你在 Vite 提的 issue 究竟是什么问题造成的，从而陷入一个对 UMD 支持这个需求的执念。后面 Evan 也说了，提 UMD 的需求解决了什么问题，这是要分析清楚的，并不是不能提。

[yyx990803]

请把我 block 掉吧

done