看了 deno, 感觉 ts 前景不可估量啊

[a132811]

感觉 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]"  

关于 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 配合时要做一点额外的配置。

[isukkaw]

然后 deno 用的 CloudFront 哪天被入侵了（就像 16 年网宿一样），然后依赖全部 GG ？
从 URL import 依赖只适合写点小玩意，但是并不意味着就可靠。

[tyrealgray]

那到时候批量升级版本的时候岂不是要改疯？

[a132811]

这一点不能否定 deno import
@isukkaw 所有的依赖都会有这个 问题。golang mod, pypi, npm 无一幸免啊。

[tonytonychopper]

package.json 里也会带版本号，我觉得像这样引入才麻烦吧，还是说除此之外还解决了什么痛点？

[a132811]

@tyrealgray 批量升级版本，靠 ide 和 vscode 就可以解决。新引入一堆包，版本冲突、不明确，带来的问题，才更容易疯。
或许，加上 import 别名 这个方案值得考虑一下。

[murmur]

以前就有 js 的 cdn，然后一个 cdn 一挂或者被墙多少网站打不开

[isukkaw]

@a132811 #3
NPM 这类依赖管理都有 SHA 校验完整性，deno 这种从 URL 就直接下来了啊。

[henvm]

@isukkaw 好奇，16 年网宿 怎么样了？可以讲讲？

[wangxiaoaer]

把依赖跟仓库绑定简直太搞笑了，包括 golang

[a132811]

@isukkaw 这个问题值得讨论啊，我的想法是 https 也足够了吧。
sha 检验完整性，要基于首次下载的 sha 也是合法的基础上。如果首次下载或者更新是 被篡改的，这个 sha 也没有啥用。
如果需要 sha 检验，deno import 也完全可以缓存包时，也生成一份 sha 啊。这个可以提 issue。


而且 deno 比 node 更关心安全，npm 的现状就相当不安全，network 以及本地的 file system 全都没有做权限 控制。在如此不安全的情况下，前端不也用得很欢快吗。

[HuHui]

导包就已经很麻烦了，你还要带个版本号

[mnssbe]

@isukkaw 依赖会本地缓存的， 如果网络缓存之前就出问题了那是有问题 ， 不过这是很多项目很多人对要面对的问题

[manami]

从这个看不出 deno 的前景，不过 ts 写起来还是很爽的，vue 3 的到来也将加快 ts 的发展！

[ipwx]

过分苛求包管理器的版本号固定本来就是本末倒置，真正应该做的是呼吁包开发者尊重 semantic version，保持基本的兼容性。毕竟是个人就会犯错，写出来的包有个小 bug 再正常不过了。一般这种解决方案就是找作者，或者提 pull request，把这个 bug 修了，版本号涨一下。

强行固定版本号的做法，相当于对将来的 bug fix 都说 no。这在前端或许还能糊弄糊弄，到后端分分钟给你黑出翔来信不信？也就是前端为主的 node 社区敢这么玩。。。

[autoxbc]

>>支持默认版本 latest 就更好
可以不带版本号，看这里的例子
https://deno.land/std/http/

有些人不理解 Deno 的模块机制为何如此设计，因为 Deno 的愿景是与浏览器同构;
即：如果脚本没有引用 Deno 内置的全局对象，那么应该可以直接运行在浏览器中

所以，Deno 尽量不脱离 ECMAScript 创造额外的概念

[azh7138m]

yarn/npm 也能带明确版本号

ts 并不需要 deno 背书

[azh7138m]

看了下
20-30k 的前端不知道 npm/yarn 可以带明确的版本号
我有点害怕

[rayhy]

不懂 js，不过想问一下，这个特性可能被 node 抄袭吗？就是在兼容原有方案的同时支持这个。一两项优点不足以让人迁移吧

[AceDogs]

Golang 不早就这样做了， 但是并没感觉出来有什么优势。Java 的 Maven 仓库用起来也很好用。npm。。。

[tonytonychopper]

@rayhy deno 貌似是 node 之父开发的，所以如果支持这个也不知道算不算抄袭 😂

[fewok]

将 java 转译成 js，感觉更有前景。。。

[optional]

@liufengsoft722 我觉得 npm 比 maven 好用。。。。除了浪费一些磁盘

[isukkaw]

@azh7138m #17
不知道 npm 和 yarn 有版本管理、不知道 HTTPS 不能保护服务器被入侵导致的投毒（ 16 年网宿数据中心被入侵导致 jsDelivr 和七牛的 CDN 服务受到严重影响），这种前端在 V2EX 掘金 SegmentFault 上比比皆是。对此不必感到吃惊、我们也只能暗自幸运我们的知识面比他们会 *略微* 宽广一些。

[Buges]

把 URL 硬编码到代码中是最睿智的行为，一个广泛使用的库维护者 GitHub 改个名字全都爆炸。
其实 npm 是非常好用的包管理，但问题是生态太乱，随便装个包后面跟几十上百个依赖一大坨小文件堆硬盘上，右键 node_modules 目录属性一看：size: xxx MB , size on disk : x.xx GB

[explore365]

@rayhy node deno 看名字

[love]

@optional 浪费磁盘也快要成过去式了，现在的 yarn2 就可以全机共享同一包文件

[janxin]

什么时候 TS 不兼容 JS 的坑我觉得更有前途...

[keelii]

有关 deno 的视频可以去我的 bilibili 了解一下。各种搬运 😂

[keelii]

https://space.bilibili.com/31831756

[otakustay]

yarn：任何需要网络的依赖安装是不明智不安全的，是会被包管理的 BUG 影响的，我们要全本地 cache，所以我们发了 yarn 2.x ！
deno：放你的狗屁，全网络依赖！

[Mohanson]

偏向看好没有历史包袱的 wasm, ts 对 js 态度暧昧，不如彻底抛弃 js。用 C 和 rust 写前端想想就刺激…

[fumichael]

@love #26 真的吗，那就是会像 maven 的本地 repo 那样？

[ipwx]

@Mohanson C 和 rust 那种语法，你还想写前端？前端 boy 连上游库的 bug fix 都不在意。。。

[azh7138m]

@fumichael 是真的。。。webpack5 支持 PnP
4 需要配置一下，也能支持
周边生态可能会炸，但总是一个好的开始（

[chiuan]

ts 还可以。但是我觉得引用是真的很烦。

[a132811]

@azh7138m @isukkaw npm/yarn 的版本控制也没有完全解决版本冲突的问题，还存在 node_module 体积爆炸问题，阿里 umi 框架初始化 node_module 就超过 1G，每次 ci/cd 上线 都是灾难。

HTTPS 不能保护服务器被入侵导致的投毒，npm 同样也不能保证不被人挂马啊。

你不能说因为 cdn 服务出现问题就 废 CDN 方案，npm 包挂马、不稳定大家不也用了这么多年了吗？而且你说的这些问题，也有很多方案，就看自己承受的成本了。安全本来就是相对的，光谈安全风险不讲自己需要的安全级别吗？
----------
ps: 我的前端知识面确实很窄，还望知识面*略微*宽广的前辈多多指教，万分感谢～

[a132811]

@otakustay 看了 yarn2 的 pnp 方案，比较期待。我记得以前 npm 有一个通过软链接共享重复包的方案，后来被放弃了。
另外 deno 的包，也同样要本地 cache 的。

[Osk]

看到网络依赖我流下了不争气的泪，可能大家还没被网络搞哭过吧。

go get, 搞不好半小时起步，再搓一点，直接无法完成。
pip install，几 kb，下至 0kb。常常失败。
npm 文件系统爆炸，xxx 框架初始化占用空间 200MB, 共 20,0000 个文件

[ericgui]

ts 前景不可估量
deno 前景，不知道

[chenxytw]

@a132811 其它不清楚，pypi 可以搞私有仓库，定期同步外网线上的就行了。类似 16 年那事，是有“可能”躲过去的 0 0

[chenluo0429]

@fewok kotlin for javascript，用起来很别扭

[tairan2006]

golang 没说必须用 GitHub 啊，golang 的私有库很容易建的

[azh7138m]

@a132811
deno 的版本控制也没有完全解决版本冲突的问题，还存在 cache 体积爆炸问题（只是你看不见了）。
$HOME/.cache Linux
$HOME/Library/Caches/deno OSX
可以看一下

umi@2 37w 依赖，它需要覆盖常见的各种开发场景，主张 all in one，开箱即用，整个 webpack 生态里面常见的 loader/plugin 都会被安装，这个体积也没啥好的办法，但并没有 1G 这么夸张。
umi@3 体积应该是变小了。

npm 可以自建源，减少不可控的程度，而且是无侵入的。

[DOLLOR]

@fewok
目前转译成 js 能称得上成功的，只有 ts 了，其他的要么昙花一现（ coffeescript ），要么误入歧途（ scala.js ），要么无人问津（ jsweet ）。不如编译成 WebAssembly，虽然这个方向在短时间内也看不到前景。

[TypeError]

@Osk #39 我都默认境外流量=墙外了，下依赖一律梯子（ proxychains/sstap/环境变量等方式）

[jieyuxue]

@isukkaw

[onfuns]

node 是前端技术发展的里程碑，而 deno 最多算造轮子，最终这个轮子会不会安到汽车上，就难说咯

[reus]

@wangxiaoaer 无知，除了源头仓库有代码，代理也有代码，本地也有代码，别人的机器上也有代码，想彻底删除一个广泛使用的库，根本是不可能的。包的导入路径只是一个名称，它不绑定到一个仓库。

[wangxiaoaer]

@reus #49 听不明白别人什么意思的就别来回复丢人了。

[reus]

@wangxiaoaer 呵呵。操你妈逼。

[a132811]

@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 碎片化 这一事实改变不了

[azh7138m]

> node_modules 爆炸的原因是高度碎片化、重复的包

yarn/npm 现在就能解决（仅限版本语义一致时）包重复的问题

依赖深不见底，体积庞大，那是生态的问题，并不是 yarn/npm 或者说是 node 本身的技术问题


umi@3 已经有了

[loading]

萌新有个疑问，npm 的包就不能以 tar 包形式存放呢，一堆碎文件，mmp。

[yuanfnadi]

@ipwx 阿里的 node 就是不锁版本的。

[ddzy]

packlock 不香吗

[linkdesu]

deno 让我比较担心的一点就是真正用在工程化的问题上以后，加上持续集成、单元测试等等一整套下来，最后还是需要 npm。如果只是做一点玩具，用不用目前的 deno 区别真的不大，别忘了我们还有个 ts-node 呢。

[dayFvckingByte]

@Osk 你可以花 1 天时间折腾一下 vpn，不然永远陷入这种生活了

[AceDogs]

@optional npm 我感觉本身因为生态的原因里面的包 可以被作者任意删除修改，maven 仓库里面的包 作者轻易删除不掉，node 项目一般放几个月就无法运行了，就是因为这个包的不兼容更新导致，有点怕，node 本身还是挺好用的。