How to handle "experimental" status when adoption is significant?
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- javascript, nodejs
- 领域
- release
调研方向
从 Node.js 稳定性指数和对 ESM 加载器的讨论开始，包括 ts-node 和 import-in-the-middle 中报告的破坏性问题。审查应如何处理已采用的实验性 API 和重大变更，包括 TSC 的参与。当 TSC 就广泛采用的实验性 API 的未来变更达成明确政策并将其记录下来时，即视为完成。
由索引模型根据 Issue 内容生成。
描述
I'm posting this here as I feel this needs TSC deliberation on the stance of the project.
We've had many things over the years stuck in "experimental" status limbo for years as things are still not ready or sometimes because they might never be ready. This is the case with async_hooks which no one wants to risk breaking because it will break the majority of users. (It's my personal goal to get abstractions or other APIs to a state where we can mark async_hooks itself as internal.) The lingering "experimental" status of some things is part of the issue I want to discuss, but moreso the disjoint between adoption and stability.
In Node.js 20 ESM loaders were moved off-thread with no flagging and no deprecation cycle around the ways existing users were using it. This broke ts-node and import-in-the-middle which is the only way for APM products to support ESM. As ESM loaders are an “experimental” feature this is technically allowed, however Node.js has historically generally approached significant changes to experimental features with broader adoption with much more care. Experimental status stages were introduced awhile ago to somewhat reflect differing stages of "experimental" status and I would have expected loaders to be marked as 1.2 at this point as it has been largely unchanged from a user perspective since v16. It also reads a bit weird to me though that 1.2 implies very nearly stable status but then the top-level description implies anything could be changed or removed at any time. Very confusing. 🤔
Anyway, I was rather surprised to see the off-thread loaders change not reverted immediately when it was discovered that it broke ts-node and import-in-the-middle. The change would have been fine if it spent some time behind a flag so users could try it out and make the necessary changes for their code to support it but this substantial refactor was released unflagged and due to being deemed ready on the day of code freeze for Node.js 20, it left zero time for the community to react. I'm sure some quality work went into the design, which I've seen on occasion when I have had the time to poke my head into the loaders code. But I feel there should have been more consideration of user impact with some effort to land the change in a way which would have been less disruptive.
As a widely adopted runtime that has in recent years been pushing hard on stability and performance to make Node.js more appealing and accommodating of enterprise users, this felt like a major step backward to me. This is the level of user consideration I would expect of the pre-1.0 days, not v20. I don't want to shame the contributors involved as I feel their work is very valuable and I would like to see loaders done, but I feel the TSC should probably be more involved in guiding larger efforts like this to ensure transitions are smoother. It's much better to take our time and focus on stable progress as it's much easier to add code to the project than it is to remove it after it's already been released. It's also not a good look when you announce a shiny new major release, especially on a line that will become LTS, and people go to try it out only to find several of the most popular tools are broken. 😅
Anyway, I hope we can better define how to handle future changes to still in-development APIs which already have user adoption so we can be a bit less disruptive in the future. As someone that writes code deployed in many, many enterprises, they get pretty cranky when I break their apps. 🙈
- 主要语言
- JavaScript
- 星标
- 693
- 派生
- 142
- 平均合并
- 8 天 7 小时
- 30 天内合并 PR
- 3
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
nodejs/TSC 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 1/100
-
难度 1/5 1 小时以内 新手友好度 20/100
-
tsc-agenda
难度 5/5 一周以上 新手友好度 8/100
-
难度 5/5 一周以上 新手友好度 3/100
-
build-agenda tsc-agenda
难度 5/5 一周以上 新手友好度 5/100
相似的 Issue
-
ai-driven-fuzzing bug claude Minor
难度 2/5 1-3 小时 新手友好度 78/100
linagora/cozy-client#1777 · 1 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
[guide] AGENTS.md claims the coverage gate, e2e and full lint run on every PR after ADR 0011 focused validation可能已有人在做 @hivecommons-hive 今天认领。 未关闭agent/guide documentation hive/claimed-by-guide stage/040-covered-by-pr
难度 2/5 1-3 小时 新手友好度 81/100
维护者通常 1 天内回复
-
check:passed feeds:add
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 4 天内回复
-
CMS video element: "CmsVideoPlugin" sets `volume = 0`, so videos cannot be unmuted on Android Chrome未关闭needs-triage Platform(Default)
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
all-contributors/cli#587 ·
维护者通常 1 天内回复