@wqsdfdddd #10 我说的"抖音"是指首页任意卡片服务后边的推荐内容，即使关闭了视频页也不影响首页留着一堆短视频。

@v1 几年没登录过闲鱼，今天下载进去一看，首页一半是各种女大学生出售摆拍照，给我看傻了

@dooono #2 太丑。

@ssh #1 首页管理下面的视频页管理关掉，我点了几百个页面才把垃圾全部清理掉，还得揣摩这些选项到底是什么玩意。

@blinue 不是，他否不否认没用，DMCA 是发给网站的，工作人员确认违反 DMCA 就会单方面删除。只要你能证明身份且证据确凿，48 小时内就会删库/下架。

发 DMCA 给 Github 和 Steam 试试，这种情况是会受理的。

我来简单总结下吧。
举个例子，本地使用 https:localhost ，浏览器需要一个受信任的证书，这里需要 mkcert 签发一个临时信任证书。
如果从其他地方例如手机访问局域网，手机的浏览器会警告，因为它没有信任证书。
那么"分布式" mkcert 如何提供证书，其实是服务端下发私有根证书。

简单来说，通过自建一个私有 CA ，安装软件等于信任这个 CA ，因此不会警告。
当然这带来了安全风险，自建方案也存在隐患。

一般情况下 vite + vite-plugin-mkcert 就行了
OP 的工具其实是解决了自动化复制 rootCA.pem 的操作。你说有用吧，确实有用，但我猜愿意用的没几个。

你应该更直接地表述这个工具到底解决了什么场景下的问题。
什么时候有用？即使用 cookie 鉴权且后端设置了 SameSite=None; Secure 且需要远程访问本地运行的项目且需要保证开发环境与实际环境完全一致。
这样就能劝退完全用不上的 99.99% 用户了。

@Jynxio #10 > 拖慢 Bundler 的 Barrel Files 主要来自库，而非业务代码
如果是库，只有第一次预构建有开销，之后全部走缓存
业务代码无法缓存，每一次变更都要重建依赖图

@TossPig #11 看不出这段 AI 废话跟我说的哪里有冲突，表达的观点是一模一样的，库有使用索引文件的正当理由，其他场景应该尽量避免。
所有 bundler 下都是必然更快，AI 总是会更保守谨慎，不敢下结论

@SanjinGG #13 我的建议是不要 export default ，使用具名导出 export { xxx }，这样可以随时重构变量名，而默认导出做不到
编辑器会收集全部 export 对象作为快速导入的候选列表，因此只要导出一次就够了，重复导出+默认导出一起用经常会遇到奇奇怪怪的 bug 。

@Jynxio #10
> 标明代码的访问权限
对于模块内，不 export 就等于私有
对于 monorepo 可以使用 package.json 的 exports 来声明外部访问列表
如果是想禁止跨模块引入，可以用 eslint
https://github.com/javierbrea/eslint-plugin-boundaries

重新导出的问题在于它只提供了一个大家约定好的入口，不能真正禁止外部引用，即使没有在入口导出，也可以全路径导入

@SanjinGG #7 自动补全跟 index.ts 没有关系，而且 index.ts 也会减慢编辑器构建自动导入缓存的速度，项目越大越明显。

@changwei #2 superbase 讨论热度高是因为适合当前 AI 一天写一个网站的环境。
这俩不好比较，因为不是一个东西，不过可以参考下这个：
https://www.devtoolsacademy.com/blog/neon-vs-supabase/

go 不适合，但 rust 写得不好更不适合。
rust 难就难在写法太多，要压榨出最佳性能可不是靠 AI 胡扯就行的。

go 如此简单你都看不懂 AI 写的代码有哪些陷阱，更不用说 rust ，我怕你来回改最后性能连 go 都不如。

@superhot #4 打包工具可以正确处理 namespace import ，例如 zod 推荐统一使用 import * as z form 'zod'
barrel 的缺点不是 tree shaking ，只要没有副作用，打包器是能正常 tree shaking ，但是开发阶段的首次启动变慢了，热更新变慢，各种 CI 检查都会变慢。因为必须加载完全部代码全能分析出用到了哪些代码，但是如果全路径定位到文件本身，就不需要对 n 个模块的复杂关系进行非常耗时的分析，因为桶文件经常会引用桶文件，几乎要把全部项目几千个文件都分析完才能梳理出单个文件的依赖图关系，哪怕它的直接依赖只有几个文件，如果只分析引用的实际依赖，整体计算量会指数级下降。

@superhot #3 IDE 会自动更新路径，除了 PR 难看点也没什么影响。
我曾经抱有相同的想法，模块内的改动不会影响到外部，这被称为封装性好。
但反过来说，它隐藏了一定的信息量
import {a} from '@/a'
import {a} from '@/a/b/c'
第二种写法是很长，但一眼就能看出这是第几层嵌套的模块，它可以培养开发者把文件当成模块的习惯，而不需要人为构造一个模块

还有一个是统一写法的问题，如果 eslint 不进行限制，同样一个导入有 n 种写法
import {a} from '@/a'
import {a} from '@/a/b'
import {a} from '@/a/b/c'
如果统一禁止掉桶文件，只有一种写法。
我能接受团队内的任何固有习惯，但我希望只能用一种习惯，不要给我第二种选择。

@craftsmanship #1 因为早期编辑器没有自动导入，为了省几个字符开发人员就想了个"巧妙"的方法少写点，现在的话没必要了，而且实际上并不会少写多少。

社区里可能有一万个惯例实际上是反模式，从来如此不一定是对的。
例如有些风格指导库会让只有一个导出时使用默认导出而非具名导出，例如 Airbnb ，在 ts 下这是错的，应该尽量避免默认导出，除非不得不用 (配置文件、i18n)。

两个缺点：
1. neon 开源部分几乎停止维护
2. 供应商锁定
除此之外没有缺点，想用就用呗，只要记得免费不等于没有代价就行