@eachann
commit 不应该按天
多人协作的时候确实清晰了很多（防杠，对我来说）

@seven777 笑死我了

腾讯里面你做不出 pdd 的活动。
我举个例子，pdd 有个下载 app 领红包的活动，页面就和 wx 里面领红包做的一样，但是你就是不能做这样的页面，立马被封，你觉得是为什么。
腾讯扶植自家流量不是一天两天了。

@jiafaner 是，国内一直是一个很奇怪的网络环境，毫无开放可言。
百度也试图用百家号做封闭流量了。

多说几句，最近中文搜索结果很多机翻垃圾站点，还有那些做垃圾站群的，我 TM***

2.7L 就选 deskmini
1L 就选 Dell 3040M （便宜，或者选更新的 7060M ）
itx 版型自己操作 可以选银欣乌鸦

有 3040M，感觉还行，不过我是 deepin。
itx 只有俩内存槽，有的时候可能比较捉鸡。
4 内存槽的妖板有点贵。

楼主平时不用 git 的吗
担忧.webp

@GeekCourse 小厂应届也能给到 10+，一年也有 15K
不如看看 fe.dog
与君共勉

别的不说，驻场的运维岂不是很惨？

@learnshare 那我给公司贡献的有点多

@azh7138m i5 7500 （
打错了

2015 是有点旧了，但是这个集显还行的，和 HD630 五五开。
我有 i7 7500 和 i7 4750HQ，接个 4K 写代码还行，楼主要是喜欢 osx 就买吧，只能说不亏。

超值的选择当然是折腾各种垃圾啦（
用什么 osx，Linux 各种发行版办公爽的一*

屏幕好 性能中上 散热好 能装内存 还要 5k
这个起步得上船了

建议加钱买 Z2 air https://www.smzdm.com/p/14042191/
活动价 5k7 叠加别的活动应该可以更低

@gzf6 直接降价会有价保的，所以都是先做活动降价，等价保时间过了，再把活动价改成正常价格

@BingoXuan 实际只是科普文介绍 https://bit-tech.net/reviews/tech/cpus/how-to-make-a-cpu-from-sand-to-shelf/1/

还不如油管的光刻机广告呢

我重新实现了一下 portfwd https://github.com/muzea/portfwd
提供了 api 可以控制转发地址 :D

16 位 16 进制，也就是 [0, 18446744073709551615]，换句话说，我只要枚举 [0, 18446744073709551616]，就必定会重复。

说白了，就是一个 64 位数，但是现在普遍认为 SHA-256 不够安全，2 ** 256 是 2 ** 64 的 6277101735386680763835789423207666416102355444464034512896 倍，是 2 ** 96 的 1461501637330902918203684832716283019655932542976 倍。

@abcbuzhiming > 只要依赖树扁平化，为何不能一个版本只存一份呢
是啊，这是两个场景
- 同一个项目
- 多个项目

对于第一种，各种管理器会尽可能的 resolve 一个依赖到同一个版本，如果可以，可能就会直接放置在项目的 node_modules 下面，哪怕它是依赖的依赖，不能的那些，还是会和原先一样，黑洞式放置

这里说到了 "尽可能的 resolve 一个依赖到同一个版本"，如果本身就是写死了不同的版本，那么包管理器也是无能为力的。

对于第二种，历史包袱也在，版本冲突问题无法妥善解决。


上面说的问题都是，需要考虑兼容性的，如果是自己的项目，没有兼容性考虑，是完全可以实现 所有项目公用依赖 的。



扁平化，不是说完全扁平化，上面说了，是"尽可能的 resolve 一个依赖到同一个版本"，本身声明依赖的版本就不同，（包管理器）是没有办法处理这种情况的。


最后，希望大家可以看下 PnP，以及社区围绕新的依赖布局的讨论，这些问题都是被讨论很多次了。

ubnt edgerouter 吗？或者考虑 cisco 的一些垃圾，路由器只做分流，然后开个机器跑代理和 DNS 服务

写个活动页生成器啊
运营在线配置活动页
炫酷活动 在线配置（

@xihefeng 不会改进
而且其他包管理器早晚会在每个项目本地搞一个依赖目录的（滑稽

npm 在这里试图解决的问题是
当你的项目 P 存在依赖 A、B、C、D 时，
P 依赖 D@1
A 依赖 D@2
B 依赖 D@3
C 依赖 D@4
这种问题是要考虑的


这里能优化的是两个场景
- 一个是已经被 yarn 和 npm 做掉的，一个项目内对一个依赖有多次依赖的时候，会尽量 resolve 到同一个版本（其实新版 npm 做的比 yarn 好，能让 node_modules 更扁平，但是带来了更多的问题（滑稽
- 另一个是楼主说的 不同的项目对一个依赖要求的版本相同的时候，能不能只存一份

后面这个有点尴尬，依赖是往上不断找 node_modules 的，按道理是可以做一个 "根 node_modules"，但是
P1 P2 依赖 D@1
P3 P4 依赖 D@2
要怎么处理呢？
symlink 也不行，webpack 的 resolve.symlinks 可以使用文件的真实路径，如果这么搞，算是 break change，非常僵硬。


或者就等，真 break change，PnP 上线吧，完全由 js 来控制 resolve 依赖的行为，新的依赖布局不需要过多考虑兼容性，能有更多的操作空间。