[vuejs/vue-cli]谁能提供一下publicPath设置成‘./’，能实际生效的方法。

目前找到一个治标不治本的方法： node_modules\@vue\cli-service\lib\Service.js 下382行，注释掉： 重新安装依赖后又需要改一次。

ps：我不知道官方写这句代码是为了什么，但是我希望，最好不要替用户做决定，这个路径写什么会带来哪些不利的后果那也是开发者自己考虑好再填的。

如果你 ./ 被改了后不能在任意目录部署项目，那是服务器的问题，不是 CLI 的问题。

我们的这个处理是完全符合 HTML 标准的。 这不叫做「替用户做决定」，这根本就不需要我们来决定什么，标准就是这样，URL 里 ./ 和空字符串等效，为什么就不能在代码里做替换了？

标准在这里：https://url.spec.whatwg.org/#path-state URL path 部分的 ./ 在解析时就是当作 empty string 处理的。

如果你非要让编译结果用上 ./，也不用改 node_modules，直接 ././ 就行，反正 Vue CLI 只处理了第一个 ./，暂时也不打算更进一步改这个逻辑。

但希望你理解，这不是 bug

如果你 ./ 被改了后不能在任意目录部署项目，那是服务器的问题，不是 CLI 的问题。

我们的这个处理是完全符合 HTML 标准的。 这不叫做「替用户做决定」，这根本就不需要我们来决定什么，标准就是这样，URL 里 ./ 和 `` 等效，为什么就不能在代码里做替换了？

最终测试，确实是我服务器的问题，不过也因此绕了一个大弯来排查。由于以前没有，现在突然新加入的，惯性思维误导了排查方向。

如果你非要让编译结果用上 ./，也不用改 node_modules，直接 ././ 就行，反正 Vue CLI 只处理了第一个 ./，暂时也不打算更进一步改这个逻辑。

但希望你理解，这不是 bug

我没有说这个是bug，只是觉得既然是等效的，那么写./与不写，结果是一样的，用户想要得到与预期相符合的结果，issue里问这个问题的也不止我一个，由此可见。

我认为用户预期应该是「相对路径」而不是「输入什么就输出什么」。

问这个问题的那么多人，要么是碰到服务器 bug，要么就是自己没理解相对路径。 为什么非要一个没有 bug 的库去费心改实现，而不是去改服务器的 bug？

重构不是没有代价的，即使理论上等效的改动，可能兼容了一部分有这个 bug 的服务器，却有可能触发另一部分原来没有问题的服务器的其他 bug，我们完全没必要在没出问题的情况下去冒这个风险。(反面例子：https://github.com/vuejs/vue-cli/pull/4816)

我认为用户预期应该是「相对路径」而不是「输入什么就输出什么」。

问这个问题的那么多人，要么是碰到服务器 bug，要么就是自己没理解相对路径。 为什么非要一个没有 bug 的库去费心改实现，而不是去改服务器的 bug？

重构不是没有代价的，即使理论上等效的改动，可能兼容了一部分有这个 bug 的服务器，却有可能触发另一部分原来没有问题的服务器的其他 bug，我们完全没必要在没出问题的情况下去冒这个风险。(反面例子：#4816)

用户预期的最终目标确实是相对路径，但用户肉眼看到的是设置./不生效，官网或者cli运行时输出也没有任何说明，那么一旦出问题，有多少人首先想到可能是设置不生效的原因，毕竟不是每个人都了解./与不写等效。但如果一开始就是写什么就是什么，用户遇到问题，就没有锅可丢了，只能从自己身上找原因，侧面减少排查的路线

那我觉得可以通过改文档来解决这个问题，而不是代码。

从我一开始提issue的时候，就没说是代码bug，而是希望让用户写什么就是什么，之前的版本一直都是，突然就变了，你看issue是不是多了几个跟我一样的问题？这次的话题不是代码有bug，而是应该有方案让用户自己选择，比如，万一有些强迫症非要./呢，就好比两个空格还是四个空格缩进。

之前的版本一直都是，突然就变了

说这话之前能不能先调查一下？？ 这个行为从 Vue CLI v3.0.0-beta.16 开始就有了，都存在一年半了，我现在要是改掉了才叫做「突然就变了」。

https://github.com/vuejs/vue-cli/commit/dc382111d95dc5cf60186b0792fb0893ff193d88 https://github.com/vuejs/vue-cli/commit/62649965ebc19cae4c2d9953736ac29847315afd

就好比两个空格还是四个空格缩进

我们设计初衷就是没必要让用户选择的就不让用户选择，所以你可以看到 Vue CLI 是没有 2 空格或 4 空格的选项的（当然要实现也是可以，就是很麻烦，这个麻烦是刻意制造的，就是为了尽量避免用户去改）。这是开源项目设计中必要的权衡。因为维护的人力有限，审美上的不同意见不能影响我们功能的开发。

之前的版本一直都是，突然就变了

说这话之前能不能先调查一下？？ 这个行为从 Vue CLI v3.0.0-beta.16 开始就有了，都存在一年半了，我现在要是改掉了才叫做「突然就变了」。

dc38211 6264996

哦，时间问题我倒是没调查过，是我的失误，但从vue可配置打包路径开始算，能写./的版本持续时长是不是比不能写的长？用户习惯导致的惯性思维有多重，你们改了这么久也不说把官网文档顺便改一下。当然，vue是开源免费的，我们不能要求这要求那的，今天是我水平有限，因为这个问题排查了一天的问题，心浮气躁，言语欠佳，谅解

Vue CLI 3/4 的文档是从头写的，所以不存在改没改的问题。

一开始并没有预期到用户会对这部分描述产生误解。

对于提过来的 issue：

• 如果认为是 bug，我已经回复过，这个实现没有错
• 如果认为需要提供选项让用户决定，我们认为，出于维护成本的考虑，不应该实现这种需求
• 如果认为需要去掉这个行为，我前面也回复了，重构不是没有代价的。所以，即使要做，我们也只会计划在下个大版本发布时改，目前不会考虑

而对于真的因为这个问题受到影响的用户：

• 真正出错的根源是服务器，我认为这不应该怪 Vue CLI
• 如果服务器问题不能很方便地绕开，Vue CLI 也可以通过配置 ././ 绕开，不明显、不美观，但够用

当然，没有错不意味着没有改进空间。 我也是直到刚刚才意识到部分用户是因为文档问题才有这个误会。

Vue CLI 是一个开源项目，所以，有不满意的地方，欢迎提 PR。

如果你非要让编译结果用上 ./，也不用改 node_modules，直接 ././ 就行，反正 Vue CLI 只处理了第一个 ./，暂时也不打算更进一步改这个逻辑。

但希望你理解，这不是 bug

我使用 ././ 会造成我 npm run serve 的时候就不能访问了 有更好的解决方案吗？

如果你非要让编译结果用上 ./，也不用改 node_modules，直接 ././ 就行，反正 Vue CLI 只处理了第一个 ./，暂时也不打算更进一步改这个逻辑。 但希望你理解，这不是 bug

我使用 ././ 会造成我 npm run serve 的时候就不能访问了 有更好的解决方案吗？

publicPath: process.env.NODE_ENV === 'production' ? '././' : '/'