#80 说前端开发的流程就是应该要删除生成目录的，我都看蒙了，而且理由居然是会占用硬盘需要手动删除。
所以是不是还不能用 node_modules，只能在 html 里远程引用 umd 的库？毕竟 node_modules 占用硬盘太多，而且居然还不能删除！

@Kittenshow 已购，同样想要 ts，tsx 的支持，还有 pac 文件的支持

@jackrelative
“因为证券投资的核心出发点就是帮助有价值的企业发展，长期持有。”

说得好，可是千万别把这句话代入 A 股😂

你的需求足够了
我刚弄完，主要是为了 openwrt （ LEDE) 做软路由：pve + LEDE + 黑裙

有一些小问题：
1. J1900 的性能不够，群晖很容易让 CPU 满载
- 挂了一个同步百度盘的任务，CPU 在同步完成之前一直满载
2. 群晖的提供的软件功能还是不够，使用上还不够省心
- Download Station 不好用，还得 Docker + Aria2，在这点上被 Windows+迅雷吊打
- Drive 默认不能访问所有文件，只能访问 drive 目录
- Moments 网页版太吃性能，后台处理照片很慢，不会自动旋转照片等。和其他照片管理软件相比随便被碾压
- Moments 手机版也被其他各种现代照片 APP 吊打，比如同步时手机发烫，其他同步 APP 基本都不会发烫了
- 网页版 APP 和手机版 APP 使用体验都不够现代，原始，而且慢

总体来说：五颗星
群晖的话：四颗星

以后可能会考虑用其他 NAS 系统替代群晖

宠物相关的话题在任何论坛社区争议都很大，没想到这里也有这么多键盘强者，我点进去看了一下，甚至有 200 多天没回复过任何帖子的强者前排口嗨，实在是佩服。

最刚开始那个表格里面的对比是怎么得出来的结论？
reeact 的开发工具支持是中，vue 是高？

上一帖没有标点符号，这帖打错字。
讨论到现在，头都没有开一个，具体讨论什么问题一个字没说。
说真的我觉得你应该深思熟虑一下再发帖，就跟写代码似的，一般最好先想好怎么解决问题才能下手吧？

啊，为啥我去医院验光，配镜失败了，根本不准

果断上 mesh

最后更是绝了，居然开始性别攻击。

32 楼居然有 3 人点赞？什么心态，都是资本家？还“臭钱”，看多了霸道总裁小说吗？

@cy476571989 #15 最后说的这个时间问题，显然不是应该依赖于打包工具吧？如果真的频繁发生这种情况，难道不是应该增加打包队列？

打包效率高是重要的，但是优先级远低于一个完整的生态。

替换掉 webpack 的前提是 webpack 会掉队，esbuild 还看不到任何可以让 webpack 掉队的 feature 。。。甚至它自己的 feature 都不完整，所以现阶段说这种话有点底气过足了吧？

目前比较期待 parcel 2 。

@sparkle2015 #13 感谢分享，但是说实话我不是很看好这种合作模式。webpack 已经很难配置了，这种合作方式不但降低不了开发成本，反而可能会因为新引入的配置问题提高复杂度。不像 parcel，它起来主要是因为真的做到了 0 配置。
另外提一下，parcel2 的开发目标也是以够快的编译为目标，说真的我不是很理解为什么大家都在求快。一般来说，使用 hot-reload 来解决开发时的效率问题就够了，1 分钟的生产打包和 10 秒钟的生产打包会有什么区别？如果真的讲求效率，反而应该是尽早进入 CI 吧？
再提一下，刚看到 esbuild 作者自己说需要思考一下 loader 的提供方式，暂时还没有实现计划: https://github.com/evanw/esbuild/pull/107#issuecomment-628448720

没有 loader，这阻碍太大了。刚试了一下，没有任何一个项目能顺利通过编译。
离生产还有点远呀，只适合一些特定环境下的应用。

yarn，pnpm 解君愁
npm 也一直在进步，但是似乎没有解决这个 nodejs 设计里留下来的问题。

一打开就弹出个加公众号的弹窗，给我吓蒙了，检查了好几遍网址，差点没敢下手

@tyhuohuo8 #86 请问一下在哪里道歉的？纯粹好奇哈