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

Spell `Selector` without the self-reference its base type holds

Aberta
  • Algo errado?
#348 1 comentário 0 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
35/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
javascript, typescript
Domínio
backend

Direção de pesquisa

Start by tracing the Selector and Container type declarations and the Node union, then reproduce the reported TS5115 with the consumer example under TypeScript 7.1 nightly. Compare the listed type spellings against the supported TypeScript versions and decide how selector children should be represented. Done means the chosen approach checks for consumers on the nightly without breaking the listed released versions.

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

Descrição

Selector no longer checks on the TypeScript 7.1 nightlies, since the nightly of 2026-09-29.

$ npm i -D typescript@next
$ tsc --noEmit --strict --skipLibCheck app.ts
app.ts(9,20): error TS5115: Instantiations of the following types appear infinitely circular: 'Container', 'Diff'.

The error is reported where Selector is used, not in the declaration, so it depends on what the consumer does with the type rather than on the package alone.

The spelling is the workaround of #232: type Selector = _Selector<Selector> over interface _Selector<S> extends Container<string, Diff<Node, S>>. No released TypeScript is affected — 4.0.3, 4.9.5, 5.0.4, 5.9.3 and 7.0.2 all check it — and the nightlies of 2026-09-28 and earlier do too.

Here is what each spelling costs, measured with tsc --noEmit --strict on a consumer that narrows a selector's children by type and reads them:

spelling of Selector 4.0.3 5.9.3 7.0.2 7.1 nightly
_Selector<S> + type Selector = _Selector<Selector>, as shipped ok ok ok TS5115
interface Selector extends Container<string, Exclude<Node, Selector>> TS2310 TS2310 TS2310 ok
interface Selector extends Container<string, Diff<Node, Selector>> TS2310 TS2310 TS2310 ok
interface Selector extends Container<string, Diff<Node, NodeTypes["selector"]>> TS2310 TS2310 TS2310 ok
type SelectorChild = Diff<Node, Selector>, Selector extends Container<string, SelectorChild> TS2310 TS2310 TS2310 ok
interface Selector<S = Selector> extends Container<string, Diff<Node, S>> errors errors errors errors
interface Selector extends Container<string, Node> ok ok ok ok

A selector that says its children are the nodes that are not selectors has to name the node union in its own base type, and that union holds Selector — which is the cycle, whichever way it is spelled. Adding a default argument to _Selector changes nothing, since the alias still names itself.

So there seem to be three ways out, and I would rather ask than pick:

  • drop the exclusion, so a selector's children are Node[]. The parser never puts a selector inside a selector, but selector.nodes was the one place in the tree that said so.
  • declare nodes on Selector itself rather than through Container, if that keeps the base type free of the node union.
  • leave it, and let the consumers on the nightly carry a patch until 7.1 ships.

We hit this in stylelint-stylistic, which pins typescript@next; the workaround there is a patchedDependencies entry that would be glad to drop once any of the lands.

Linguagem predominante
JavaScript
Estrelas
216
Forks
81
Nenhum PR com merge em 30d

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

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 postcss/postcss-selector-parser

Todas as issues de postcss/postcss-selector-parser

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.