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

[a132811]

感觉 deno 这种明确带版本号的引入方式，才是解决版本依赖的最佳方式，简洁、明确、不混淆，或许能产生比 npm 更强的生态。

import { serve } from "https://deno.land/std@v0.30.0/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/[e-mail]"  
	import echo_v2_1_0 from "cdn_npm/[e-mail]"  

[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 本身还是挺好用的。