[Bug]: 3.0 版本后使用 npm 安装失败，提示 Unsupported URL Type "workspace:": workspace:1.0.0-alpha.5

[yy4382]

问题描述 | Describe the bug

尝试在一个vue项目中引入waline时

$ npm i @waline/client             
npm ERR! code EUNSUPPORTEDPROTOCOL
npm ERR! Unsupported URL Type "workspace:": workspace:1.0.0-alpha.5

如果使用yarn，会让我选择：

? Please choose a version of "@waline/api" from this list: (Use arrow keys)
❯ 1.0.0-alpha.5 
  1.0.0-alpha.4 
  1.0.0-alpha.3 
  1.0.0-alpha.2 
  1.0.0-alpha.1 
  1.0.0-alpha.0 

好像是新的 @waline/api 引入的问题？

在本机、docker容器中和GitHub Actions中尝试安装，都失败了，应该不是我环境的问题。

问题网站 | Website URL

null

服务部署在哪里？ | Where your waline deploy?

Self Host

数据存储在哪里？| Where your comment data store?

PostgreSQL

[lizheming]

@Mister-Hope 是不是这些依赖应该都放在 devDep 里面？https://github.com/walinejs/waline/blob/main/packages/client/package.json#L84-L92

---

@Mister-Hope Should all these dependencies be placed in devDep? https://github.com/walinejs/waline/blob/main/packages/client/package.json#L84-L92

[Mister-Hope]

Nope,.the slim bundle is the default entry on node, so perhaps your workflow are still problematic.

[lizheming]

@Mister-Hope 有两种解决办法，一种是将 @waline/api 打包进去，这样能保持 @waline/api 是跟随仓库最新的；还有一种方案是构建前修改 package.json 将其指向到 npm 最新的版本号上。你选一个我再改吧。

---

@Mister-Hope There are two solutions. One is to package @waline/api, so as to keep @waline/api up to date with the warehouse; the other is to modify package.json before building Point it to the latest npm version number. You choose one and I'll change it.

[Mister-Hope]

原则上使用workspace:* 对于pnpm发布是没问题的。只是ci有问题而已

---

In principle, there is no problem using workspace:* for pnpm publishing. It’s just a problem with ci

[lizheming]

@Mister-Hope CI和发布都没有问题，现在是package.json中依赖写的还是workspace，所以导致了在其他项目里安装出错了。这种monorepo项目的依赖内部引用一般对外的产物都是bundle后文件，所以前端引用bundle后的产物是没有问题的，所以我才提了第一个问题是否是放在devDep的。如果要提供未bundle的版本给node使用的话，要么就是把workspace的依赖bundle进去，要么就是workspace的依赖发包改成非workspace依赖，对应着我说的两个方案。

---

@Mister-Hope There are no problems with CI and release. Now the dependencies in package.json are written in workspace, which causes installation errors in other projects. This kind of monorepo project relies on internal references. Generally, the external products are bundled files, so there is no problem in the front end referencing the bundled products, so I asked the first question whether it is placed in devDep. If you want to provide an unbundled version for node to use, you must either add the workspace dependency into the bundle, or change the workspace dependency outsourcing to a non-workspace dependency, which corresponds to the two solutions I mentioned.

[Mister-Hope]

大哥别犟，我之前特意开了issue。如果你使用 pnpm publish命令发布任何含有workspace 协议的任何包，那么他们会在发布时基于workspace相关依赖的版本自动转换到对应的版本号范围。本质上就是你 CI 发布有问题。

换言之，无论是 dep peerDep 还是 devDep 的依赖，workspace protocal都是没问题，对于本地是 1.0.0 的版本，workspace:* workspace:~ workspace:^ 会自动通过 pnpm 发布的时候转换为 "1.0.0" "~1.0.0" 和 "^1.0.0"。

我不是很了解 npm 对于只能在特定 CI/CD 环境的限制具体有什么，但是一个最起码的解决办法是改一下workflow 自己手动检测当前版本是否已发布并手动 pnpm publish（如需要）

---

Brother, don't be stubborn, I specially opened an issue before. If you use the pnpm publish command to publish any package containing the workspace protocol, they will automatically be converted to the corresponding version number range based on the version of the workspace-related dependencies when publishing. Essentially, there is a problem with your CI release.

In other words, whether it is a dependency on dep peerDep or devDep, the workspace protocol is no problem. For the local version 1.0.0, workspace:* workspace:~ workspace:^ will automatically be converted to "1.0.0" when published through pnpm "~1.0.0" and "^1.0.0".

I don't know much about npm's specific restrictions on specific CI/CD environments, but a minimum solution is to change the workflow to manually detect whether the current version has been published and manually pnpm publish (if necessary)

[lizheming]

@Mister-Hope 我觉得你可能没听明白我说的话的意思。那就按照你的理解来吧，CI 发布有问题，有两个解决方案，你选择一种，我来修改。

---

@Mister-Hope I think you may not understand what I mean. Then follow your understanding. There is a problem with CI release. There are two solutions. You choose one and I will modify it.

[Mister-Hope]

我觉得我充分理解了你要表达的意思，但我不觉得你的观点是对的。

握有大量包含monorepo的项目都在用 pnpm，比如 vuepress/core vuepress/ecosystem vuepress-theme-hope/vuepress-theme-hope mdit-plugins/mdit-plugins 之类的。

1. 包管理器使用要一致，而且像corepack这种东西已经很成熟了，比如 corepack use npm 就直接能把当前的项目从任意包管理器换成 npm。我不能理解 pnpm 的项目用 npm publish 的方式来发包，就是这里的workspace的问题。npm不支持 workspace，也自然不需要再 publish 的时候对这种特殊版本做处理。

2. 这种monorepo项目的依赖内部引用一般对外的产物都是bundle后文件。

   我不能理解这种错误结论是从哪得出来的，所有针对 node 的 monorepo 发包的时候都不会 bundle，做一个需要 CDN 通过浏览器来使用的包在前端才是特例。我上面举的所有例子都没有打包 monorepo 内其他包的行为。就拿这个项目本身的依赖来说，@typescript-eslint @commitlint 等包也不是你所说的这么干。

（仅技术性讨论）

---

I think I fully understand what you're trying to say, but I don't think your point is correct.

A large number of projects containing monorepo are using pnpm, such as vuepress/core vuepress/ecosystem vuepress-theme-hope/vuepress-theme-hope mdit-plugins/mdit-plugins and the like.

1. Package managers must be used consistently, and things like corepack are already very mature. For example, corepack use npm can directly change the current project from any package manager to npm. I can't understand that pnpm projects use npm publish to deliver packages. It's a problem with the workspace here. npm does not support workspace, so there is no need to handle this special version when publishing.

2. The dependencies of this monorepo project are internally referenced and generally the external products are bundle files.

   I can't understand where this wrong conclusion comes from. All monorepo packages for node will not be bundled. Making a package that requires CDN to be used through the browser is a special case on the front end. All the examples I gave above do not include the behavior of packaging other packages within the monorepo. Take the dependencies of the project itself as an example. Packages such as @typescript-eslint @commitlint do not do what you said.

(Technical discussion only)

[lizheming]

@Mister-Hope

1. 包管理器要使用一致，这个是有待商榷的结论，先不说它是不是完全正确的吧。我没有按照你的思路选择 pnpm publish 的原因是，市面上暂时没有比较好的集成 pnpm publish 的 GitHub Action。而现有的 https://github.com/JS-DevTools/npm-publish 工具比较好的点是能够识别版本号再做发布相关的逻辑，能比较好的根据不同 case 返回发布的状态。综合换工具和适配的成本，我选择了后者适配。
2. 首先，我说的是“一般”，其次，这也不是错误的结论。就你举例的两个案例我都去看了，typescript-eslint 的 workspace 依赖是在 workspaceRoot 的，不存在需要发布的场景。而 commitlint 我没找到它有 workspace 依赖的行为，或者它使用 yarn 的 workspace 的依赖书写规则和 pnpm 不太一样，我没有看到同类的场景可以参考。

按照你说的 pnpm 的行为，我认为你会选择提到的方案二，那我就不多说了按照二来处理吧。

---

@Mister-Hope

1. Package managers should be used consistently. This is a debatable conclusion, let’s not say whether it is completely correct. The reason why I didn't choose pnpm publish according to your idea is that there is currently no better GitHub Action integrating pnpm publish on the market. The existing https://github.com/JS-DevTools/npm-publish tool is better in that it can identify the version number and then perform release-related logic, and it can better return the release status according to different cases. Considering the cost of tool replacement and adaptation, I chose the latter adaptation.
2. First of all, I said "generally", and secondly, this is not a wrong conclusion. I have looked at the two cases you gave. The workspace dependency of typescript-eslint is in the workspaceRoot, and there is no scenario where it needs to be released. As for commitlint, I didn't find that it has workspace dependency behavior, or that the dependency writing rules of yarn's workspace are different from pnpm. I haven't seen similar scenarios for reference.

According to the behavior of pnpm you mentioned, I think you will choose the second option mentioned, so I won’t go into details and just handle it according to the second option.

[lizheming]

fixed with #2333 please update to @waline/[email protected]