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

2020-03-07 18:08:12 +08:00
 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/echo@2.1.1.ts"  
	import echo_v2_1_0 from "cdn_npm/echo@2.1.0.ts"  
13603 次点击
所在节点    程序员
59 条回复
isukkaw
2020-03-07 18:14:50 +08:00
然后 deno 用的 CloudFront 哪天被入侵了(就像 16 年网宿一样),然后依赖全部 GG ?
从 URL import 依赖只适合写点小玩意,但是并不意味着就可靠。
tyrealgray
2020-03-07 18:19:46 +08:00
那到时候批量升级版本的时候岂不是要改疯?
a132811
2020-03-07 18:21:17 +08:00
这一点不能否定 deno import
@isukkaw 所有的依赖都会有这个 问题。golang mod, pypi, npm 无一幸免啊。
tonytonychopper
2020-03-07 18:25:42 +08:00
package.json 里也会带版本号,我觉得像这样引入才麻烦吧,还是说除此之外还解决了什么痛点?
a132811
2020-03-07 18:26:46 +08:00
@tyrealgray 批量升级版本,靠 ide 和 vscode 就可以解决。新引入一堆包,版本冲突、不明确,带来的问题,才更容易疯。
或许,加上 import 别名 这个方案值得考虑一下。
murmur
2020-03-07 18:28:55 +08:00
以前就有 js 的 cdn,然后一个 cdn 一挂或者被墙多少网站打不开
isukkaw
2020-03-07 18:29:28 +08:00
@a132811 #3
NPM 这类依赖管理都有 SHA 校验完整性,deno 这种从 URL 就直接下来了啊。
henvm
2020-03-07 18:35:30 +08:00
@isukkaw 好奇,16 年网宿 怎么样了?可以讲讲?
wangxiaoaer
2020-03-07 18:40:18 +08:00
把依赖跟仓库绑定简直太搞笑了,包括 golang
a132811
2020-03-07 18:41:20 +08:00
@isukkaw 这个问题值得讨论啊,我的想法是 https 也足够了吧。
sha 检验完整性,要基于首次下载的 sha 也是合法的基础上。如果首次下载或者更新是 被篡改的,这个 sha 也没有啥用。
如果需要 sha 检验,deno import 也完全可以缓存包时,也生成一份 sha 啊。这个可以提 issue。


而且 deno 比 node 更关心安全,npm 的现状就相当不安全,network 以及本地的 file system 全都没有做权限 控制。在如此不安全的情况下,前端不也用得很欢快吗。
HuHui
2020-03-07 18:41:38 +08:00
导包就已经很麻烦了,你还要带个版本号
mnssbe
2020-03-07 18:43:52 +08:00
@isukkaw 依赖会本地缓存的, 如果网络缓存之前就出问题了那是有问题 , 不过这是很多项目很多人对要面对的问题
manami
2020-03-07 19:09:00 +08:00
从这个看不出 deno 的前景,不过 ts 写起来还是很爽的,vue 3 的到来也将加快 ts 的发展!
ipwx
2020-03-07 19:31:42 +08:00
过分苛求包管理器的版本号固定本来就是本末倒置,真正应该做的是呼吁包开发者尊重 semantic version,保持基本的兼容性。毕竟是个人就会犯错,写出来的包有个小 bug 再正常不过了。一般这种解决方案就是找作者,或者提 pull request,把这个 bug 修了,版本号涨一下。

强行固定版本号的做法,相当于对将来的 bug fix 都说 no。这在前端或许还能糊弄糊弄,到后端分分钟给你黑出翔来信不信?也就是前端为主的 node 社区敢这么玩。。。
autoxbc
2020-03-07 19:50:06 +08:00
>>支持默认版本 latest 就更好
可以不带版本号,看这里的例子
https://deno.land/std/http/

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

所以,Deno 尽量不脱离 ECMAScript 创造额外的概念
azh7138m
2020-03-07 19:59:54 +08:00
yarn/npm 也能带明确版本号

ts 并不需要 deno 背书
azh7138m
2020-03-07 20:01:12 +08:00
看了下
20-30k 的前端不知道 npm/yarn 可以带明确的版本号
我有点害怕
rayhy
2020-03-07 20:03:40 +08:00
不懂 js,不过想问一下,这个特性可能被 node 抄袭吗?就是在兼容原有方案的同时支持这个。一两项优点不足以让人迁移吧
AceDogs
2020-03-07 20:08:33 +08:00
Golang 不早就这样做了, 但是并没感觉出来有什么优势。Java 的 Maven 仓库用起来也很好用。npm。。。
tonytonychopper
2020-03-07 20:09:39 +08:00
@rayhy deno 貌似是 node 之父开发的,所以如果支持这个也不知道算不算抄袭 😂

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/650730

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX