Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

How to handle "experimental" status when adoption is significant?

Aberta
  • Algo errado?
#1,397 17 comentários 5 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
javascript, nodejs
Domínio
release

Direção de pesquisa

Comece pelo índice de estabilidade do Node.js e pela discussão sobre os carregadores ESM, incluindo as quebras relatadas no ts-node e no import-in-the-middle. Revise como APIs experimentais adotadas e grandes mudanças devem ser tratadas, incluindo o envolvimento do TSC. O trabalho estará concluído quando o TSC chegar a uma política clara para mudanças futuras em APIs experimentais amplamente adotadas e a documentar.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

question

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. 🙈

Linguagem predominante
JavaScript
Estrelas
693
Forks
143
Merge médio
8d 7h
PRs com merge (30d)
3

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de nodejs/TSC

Todas as issues de nodejs/TSC

Issues semelhantes

Mais issues de JavaScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.