这是一个创建于 1730 天前的主题，其中的信息可能已经有所发展或是发生改变。
感觉 deno 这种明确带版本号的引入方式，才是解决版本依赖的最佳方式，简洁、明确、不混淆，或许能产生比 npm 更强的生态。
import { serve } from "https://deno.land/[email protected]/http/server.ts";
const s = serve({ port: 8000 });
console.log("http://localhost:8000/");
for await (const req of s) {
req.respond({ body: "Hello World\n" });
}
终于不用再被 package.json 和 node_module 以及 AMD-CMD 折磨了。
就是在文件中手写 url 有点麻烦，要是能支持 domain 的 alias、支持默认版本 latest 就更好。
// .deno/config
const cdn_npm = 'https://npm.cdn.deno';
// main.ts
import echo_latest from "cdn_npm/echo.ts"
import echo_v2_1_1 from "cdn_npm/[email protected]"
import echo_v2_1_0 from "cdn_npm/[email protected]"
第 1 条附言 · 2020-03-09 20:40:53 +08:00
关于 url+version 导致项目升级版本麻烦的问题。deno 有一个更干净的方案，用全局的 deps.ts 代替 package.json
```
// deps.ts
export {
assert,
assertEquals,
assertStrContains
} from "https://deno.land/std/testing/v0.1.1/asserts.ts";
// app.ts
import { assertEquals, runTests, test } from "./deps.ts";
```
围绕 deps.ts ，我们可以编写版本管理命令行工具。
node 的 PnP 方案解决了 node_modules 重复包问题，这个方案还不像 deno 那么简洁。Pnp 方案在安装时要层层解析 package.json，然后要维护一张很大的.pnp.js 映射表。PnP 与现有项目、vsocde/typescript 配合时要做一点额外的配置。
```
// deps.ts
export {
assert,
assertEquals,
assertStrContains
} from "https://deno.land/std/testing/v0.1.1/asserts.ts";
// app.ts
import { assertEquals, runTests, test } from "./deps.ts";
```
围绕 deps.ts ，我们可以编写版本管理命令行工具。
node 的 PnP 方案解决了 node_modules 重复包问题，这个方案还不像 deno 那么简洁。Pnp 方案在安装时要层层解析 package.json，然后要维护一张很大的.pnp.js 映射表。PnP 与现有项目、vsocde/typescript 配合时要做一点额外的配置。
 |
1
isukkaw 2020-03-07 18:14:50 +08:00
然后 deno 用的 CloudFront 哪天被入侵了（就像 16 年网宿一样），然后依赖全部 GG ？
从 URL import 依赖只适合写点小玩意，但是并不意味着就可靠。 |
 |
2
tyrealgray 2020-03-07 18:19:46 +08:00
那到时候批量升级版本的时候岂不是要改疯？
|
 |
3
a132811 OP 这一点不能否定 deno import
@isukkaw 所有的依赖都会有这个 问题。golang mod, pypi, npm 无一幸免啊。 |
 |
4
tonytonychopper 2020-03-07 18:25:42 +08:00
package.json 里也会带版本号，我觉得像这样引入才麻烦吧，还是说除此之外还解决了什么痛点？
|
|
5
a132811 OP @tyrealgray 批量升级版本，靠 ide 和 vscode 就可以解决。新引入一堆包，版本冲突、不明确，带来的问题，才更容易疯。
或许，加上 import 别名 这个方案值得考虑一下。 |
 |
6
murmur 2020-03-07 18:28:55 +08:00  1
以前就有 js 的 cdn，然后一个 cdn 一挂或者被墙多少网站打不开
|
 |
9
wangxiaoaer 2020-03-07 18:40:18 +08:00 via Android 9
把依赖跟仓库绑定简直太搞笑了，包括 golang
|
|
10
a132811 OP @isukkaw 这个问题值得讨论啊，我的想法是 https 也足够了吧。
sha 检验完整性，要基于首次下载的 sha 也是合法的基础上。如果首次下载或者更新是 被篡改的，这个 sha 也没有啥用。 如果需要 sha 检验，deno import 也完全可以缓存包时，也生成一份 sha 啊。这个可以提 issue。 而且 deno 比 node 更关心安全，npm 的现状就相当不安全，network 以及本地的 file system 全都没有做权限 控制。在如此不安全的情况下，前端不也用得很欢快吗。 |
 |
11
HuHui 2020-03-07 18:41:38 +08:00 via Android
导包就已经很麻烦了，你还要带个版本号
|
 |
13
manami 2020-03-07 19:09:00 +08:00 via Android
从这个看不出 deno 的前景，不过 ts 写起来还是很爽的，vue 3 的到来也将加快 ts 的发展！
|
 |
14
ipwx 2020-03-07 19:31:42 +08:00 3
过分苛求包管理器的版本号固定本来就是本末倒置，真正应该做的是呼吁包开发者尊重 semantic version，保持基本的兼容性。毕竟是个人就会犯错，写出来的包有个小 bug 再正常不过了。一般这种解决方案就是找作者，或者提 pull request，把这个 bug 修了，版本号涨一下。
强行固定版本号的做法，相当于对将来的 bug fix 都说 no。这在前端或许还能糊弄糊弄，到后端分分钟给你黑出翔来信不信？也就是前端为主的 node 社区敢这么玩。。。 |
 |
15
autoxbc 2020-03-07 19:50:06 +08:00
>>支持默认版本 latest 就更好
可以不带版本号，看这里的例子 https://deno.land/std/http/ 有些人不理解 Deno 的模块机制为何如此设计，因为 Deno 的愿景是与浏览器同构; 即：如果脚本没有引用 Deno 内置的全局对象，那么应该可以直接运行在浏览器中 所以，Deno 尽量不脱离 ECMAScript 创造额外的概念 |
 |
16
azh7138m 2020-03-07 19:59:54 +08:00 via Android
yarn/npm 也能带明确版本号
ts 并不需要 deno 背书 |
|
17
azh7138m 2020-03-07 20:01:12 +08:00 via Android
看了下
20-30k 的前端不知道 npm/yarn 可以带明确的版本号 我有点害怕 |
 |
18
rayhy 2020-03-07 20:03:40 +08:00 via Android
不懂 js，不过想问一下，这个特性可能被 node 抄袭吗？就是在兼容原有方案的同时支持这个。一两项优点不足以让人迁移吧
|
 |
19
AceDogs 2020-03-07 20:08:33 +08:00
Golang 不早就这样做了， 但是并没感觉出来有什么优势。Java 的 Maven 仓库用起来也很好用。npm。。。
|
|
20
tonytonychopper 2020-03-07 20:09:39 +08:00
@rayhy deno 貌似是 node 之父开发的，所以如果支持这个也不知道算不算抄袭 😂
|
 |
21
fewok 2020-03-07 20:15:40 +08:00
将 java 转译成 js，感觉更有前景。。。
|
 |
22
optional 2020-03-07 20:26:32 +08:00 via iPhone
@liufengsoft722 我觉得 npm 比 maven 好用。。。。除了浪费一些磁盘
|
|
23
isukkaw 2020-03-07 20:33:07 +08:00
@azh7138m #17
不知道 npm 和 yarn 有版本管理、不知道 HTTPS 不能保护服务器被入侵导致的投毒（ 16 年网宿数据中心被入侵导致 jsDelivr 和七牛的 CDN 服务受到严重影响），这种前端在 V2EX 掘金 SegmentFault 上比比皆是。对此不必感到吃惊、我们也只能暗自幸运我们的知识面比他们会 *略微* 宽广一些。 |
 |
24
Buges 2020-03-07 20:44:57 +08:00 via Android
把 URL 硬编码到代码中是最睿智的行为，一个广泛使用的库维护者 GitHub 改个名字全都爆炸。
其实 npm 是非常好用的包管理，但问题是生态太乱，随便装个包后面跟几十上百个依赖一大坨小文件堆硬盘上，右键 node_modules 目录属性一看：size: xxx MB , size on disk : x.xx GB |
 |
25
explore365 2020-03-07 20:53:52 +08:00
@rayhy node deno 看名字
|
 |
27
janxin 2020-03-07 21:09:04 +08:00 3
什么时候 TS 不兼容 JS 的坑我觉得更有前途...
|
 |
28
keelii 2020-03-07 21:15:55 +08:00
有关 deno 的视频可以去我的 bilibili 了解一下。各种搬运 😂
|
|
29
keelii 2020-03-07 21:16:02 +08:00
|
 |
30
otakustay 2020-03-07 21:25:02 +08:00 8
yarn：任何需要网络的依赖安装是不明智不安全的，是会被包管理的 BUG 影响的，我们要全本地 cache，所以我们发了 yarn 2.x ！
deno：放你的狗屁，全网络依赖！ |
 |
31
Mohanson 2020-03-07 21:33:11 +08:00 via Android
偏向看好没有历史包袱的 wasm, ts 对 js 态度暧昧，不如彻底抛弃 js。用 C 和 rust 写前端想想就刺激…
|
|
35
azh7138m 2020-03-07 22:56:44 +08:00 via Android
|
 |
36
chiuan 2020-03-07 22:57:44 +08:00
ts 还可以。但是我觉得引用是真的很烦。
|
|
37
a132811 OP @azh7138m @isukkaw npm/yarn 的版本控制也没有完全解决版本冲突的问题，还存在 node_module 体积爆炸问题，阿里 umi 框架初始化 node_module 就超过 1G，每次 ci/cd 上线 都是灾难。
HTTPS 不能保护服务器被入侵导致的投毒，npm 同样也不能保证不被人挂马啊。 你不能说因为 cdn 服务出现问题就 废 CDN 方案，npm 包挂马、不稳定大家不也用了这么多年了吗？而且你说的这些问题，也有很多方案，就看自己承受的成本了。安全本来就是相对的，光谈安全风险不讲自己需要的安全级别吗？ ---------- ps: 我的前端知识面确实很窄，还望知识面*略微*宽广的前辈多多指教，万分感谢～ |
|
38
a132811 OP @otakustay 看了 yarn2 的 pnp 方案，比较期待。我记得以前 npm 有一个通过软链接共享重复包的方案，后来被放弃了。
另外 deno 的包，也同样要本地 cache 的。 |
 |
39
Osk 2020-03-08 08:27:27 +08:00 via Android
看到网络依赖我流下了不争气的泪，可能大家还没被网络搞哭过吧。
go get, 搞不好半小时起步，再搓一点，直接无法完成。 pip install，几 kb，下至 0kb。常常失败。 npm 文件系统爆炸，xxx 框架初始化占用空间 200MB, 共 20,0000 个文件 |
 |
40
ericgui 2020-03-08 08:46:09 +08:00
ts 前景不可估量
deno 前景，不知道 |
 |
41
chenxytw 2020-03-08 09:44:38 +08:00
@a132811 其它不清楚，pypi 可以搞私有仓库，定期同步外网线上的就行了。类似 16 年那事，是有“可能”躲过去的 0 0
|
 |
42
chenluo0429 2020-03-08 10:08:39 +08:00 via Android
@fewok kotlin for javascript，用起来很别扭
|
 |
43
tairan2006 2020-03-08 10:57:36 +08:00
golang 没说必须用 GitHub 啊，golang 的私有库很容易建的
|
|
44
azh7138m 2020-03-08 11:57:59 +08:00 via Android
@a132811
deno 的版本控制也没有完全解决版本冲突的问题，还存在 cache 体积爆炸问题（只是你看不见了）。 $HOME/.cache Linux $HOME/Library/Caches/deno OSX 可以看一下 umi@2 37w 依赖，它需要覆盖常见的各种开发场景，主张 all in one，开箱即用，整个 webpack 生态里面常见的 loader/plugin 都会被安装，这个体积也没啥好的办法，但并没有 1G 这么夸张。 umi@3 体积应该是变小了。 npm 可以自建源，减少不可控的程度，而且是无侵入的。 |
 |
45
DOLLOR 2020-03-08 12:53:02 +08:00
@fewok
目前转译成 js 能称得上成功的，只有 ts 了，其他的要么昙花一现（ coffeescript ），要么误入歧途（ scala.js ），要么无人问津（ jsweet ）。不如编译成 WebAssembly，虽然这个方向在短时间内也看不到前景。 |
 |
48
onfuns 2020-03-08 15:36:44 +08:00
node 是前端技术发展的里程碑，而 deno 最多算造轮子，最终这个轮子会不会安到汽车上，就难说咯
|
 |
49
reus 2020-03-08 17:21:19 +08:00 via Android
@wangxiaoaer 无知，除了源头仓库有代码，代理也有代码，本地也有代码，别人的机器上也有代码，想彻底删除一个广泛使用的库，根本是不可能的。包的导入路径只是一个名称，它不绑定到一个仓库。
|
|
50
wangxiaoaer 2020-03-08 17:25:43 +08:00
@reus #49 听不明白别人什么意思的就别来回复丢人了。
|
|
51
reus 2020-03-08 17:30:06 +08:00 via Android
@wangxiaoaer 呵呵。操你妈逼。
|
|
52
a132811 OP @Osk 你那是墙的问题，不能怪网络。pypi/npm/golang/docker/maven 可以用 artifactory 这一类工具统一建镜像。
@azh7138m deno cache 的体积哪有你说的那么 爆炸。deno 的 cache 目录结构明确单一。 它应该跟~/.npm 这个 cache 目录一一对应才对，不能跟 node_modules 相提并论(deno 目的就是砍掉 node_modules)。node_modules 爆炸的原因是高度碎片化、重复的包(除非开启 yarn pnp) umi@2 创建 antd-pro 时，我没有记错的话，不加 puppeteer 这个依赖的话就有 1.3G 的 node_modules。node_modules 额外造成的体积臃肿，这事跟 all_in_one 和开箱即用是两码事。 umi@3 还没有发版吧，但我不觉得其体积能显著减少，毕竟 npm 碎片化 这一事实改变不了 |
|
53
azh7138m 2020-03-08 22:08:55 +08:00 via Android
> node_modules 爆炸的原因是高度碎片化、重复的包
yarn/npm 现在就能解决（仅限版本语义一致时）包重复的问题 依赖深不见底，体积庞大，那是生态的问题，并不是 yarn/npm 或者说是 node 本身的技术问题 umi@3 已经有了 |
 |
54
loading 2020-03-08 22:19:25 +08:00 via Android
萌新有个疑问，npm 的包就不能以 tar 包形式存放呢，一堆碎文件，mmp。
|
 |
56
ddzy 2020-03-09 19:34:12 +08:00
packlock 不香吗
|
 |
57
linkdesu 2020-03-10 12:32:40 +08:00
deno 让我比较担心的一点就是真正用在工程化的问题上以后，加上持续集成、单元测试等等一整套下来，最后还是需要 npm。如果只是做一点玩具，用不用目前的 deno 区别真的不大，别忘了我们还有个 ts-node 呢。
|
 |
58
dayFvckingByte 2020-05-14 10:05:18 +08:00
@Osk 你可以花 1 天时间折腾一下 vpn，不然永远陷入这种生活了
|
Select Language