Less.js: ES6 & rollup

Não. Eu tenho pensado na mesma linha por um tempo. Que tal usar o TypeScript? Pode facilitar o desenvolvimento/contribuições ter dicas de código/vinculação de objetos reais. Embora eu não saiba se isso colocaria uma carga / barreira de conhecimento então.

Eu também estava pensando na mesma linha que devemos considerar o uso de coleções es6 para análise / AST e, em seguida, usar um polyfill para compilações es5 como https://github.com/Benvie/harmony-collections. Em ambientes es6 (que o Node.js agora é, assim como os navegadores mais recentes), isso teoricamente deve acelerar a análise/avaliação devido à sobrecarga de memória reduzida e à construção mais rápida de AST.

Que tal usar o TypeScript? Pode facilitar o desenvolvimento/contribuições ter dicas de código/vinculação de objetos reais. Embora eu não saiba se isso colocaria uma carga / barreira de conhecimento então.

Podemos considerar que depois de ES6 - es6 não exclui o typescript já que o typescript também é um transpilador es6 .. seria um passo adicional depois disso.

Eu pessoalmente não recomendaria o texto datilografado a menos que houvesse um trabalho extra significativo ou refatoração em menos. Texto datilografado IMO

• + facilita o desenvolvimento para novas pessoas que conhecem o texto datilografado
• + aumenta a manutenção
• 
  
  • requer que as pessoas conheçam ou aprendam uma quantidade mínima de texto datilografado
  
  
• 
  
  • leva mais tempo para escrever o código para que seja digitado
  
  

Eu também estava pensando na mesma linha que devemos considerar o uso de coleções es6 para análise / AST e, em seguida, usar um polyfill para compilações es5 como https://github.com/Benvie/harmony-collections. Em ambientes es6 (que o Node.js agora é, assim como os navegadores mais recentes), isso teoricamente deve acelerar a análise/avaliação devido à sobrecarga de memória reduzida e à construção mais rápida de AST.

Eu não usaria esse polyfill, o projeto parece morto (talvez também porque o nome harmonia esteja morto).

Também, infelizmente, eu não teria certeza de que os equivalentes nativos do ES6 são mais rápidos - https://jsperf.com/property-access-object-array-map-weakmap/6. É triste como, por exemplo, o polyfill Promise é mais rápido que a implementação nativa :(

:+1:

Todos os pontos positivos. Padronizar no ES6 / Babel geralmente torna as coisas não apenas mais fáceis de escrever, mas também de ler, especialmente ao fazer herança prototípica.

Quanto ao teste jsperf, não é realmente um exemplo justo. Eu esperaria que o Weakmap tivesse um desempenho mais lento para esse teste específico. Em teoria, pode ser melhor para Less criar um monte de formas e tipos de objetos diferentes e depois avaliá-los. Não tenho certeza. Encontrei algumas boas bibliotecas que quero testar (e espero adicionar) onde podemos conectar funções individuais para fazer benchmarking granular, sem ter que colocar nenhum "gancho de benchmark" na lib. Espero configurar algo (quando tiver tempo, quem sabe quando será) para que você possa fazer uma espécie de teste jsperf em funções dentro do Less.js, mas com desenvolvimento local / mudanças de branch para Less vs. versão atual e usando alguns tipos de arquivos .less de teste. Como mencionei antes, não deveríamos precisar adivinhar qual é mais rápido para nosso caso de uso específico. Teoricamente, poderíamos inserir um WeakMap em algum nível de função versus objetos brutos, executar benchmarks nesse local e decidir com base no resultado.

@lukeapage escreveu:
Texto datilografado IMO

• + facilita o desenvolvimento para novas pessoas que conhecem o texto datilografado
• + aumenta a manutenção
• 
  
  • requer que as pessoas conheçam ou aprendam uma quantidade mínima de texto datilografado
  
  
• 
  
  • leva mais tempo para escrever o código para que seja digitado
  
  

E um benefício não mencionado e muito significativo que você está ignorando:
O modo tipado do TypeScript força você a usar tipos de variáveis ​​estáveis, o que impõe formas de tipo estáveis, o que melhora a capacidade do compilador de analisar tanto estaticamente _e_ dinamicamente seu código, que produz código otimizado _muito melhor_ e interrompe (ou pelo menos reduz drasticamente) backouts de código otimizado de volta ao código interpretado lento.

A mudança para o TypeScript provavelmente contribuiria mais do que a mudança para o ES6, imho.

Por modo digitado você quer dizer o proibir Qualquer?

Eu tentei isso em um pequeno projeto e tinha anotações em todos os lugares.
com um monte de código porque o transpilador não é super inteligente.

quanto a quantas variáveis ​​mudaram os tipos de variáveis, não tenho certeza. assim..
não convencido de que o benefício de desempenho seria perceptível.

@rjgotten Eu não usei o TypeScript, mas esses são bons pontos. Se você estiver usando um ambiente intellisense/autocomplete para TypeScript, ele pode realmente ajudar novos contribuidores, pois concluiria tipos/formas de objetos à medida que você faz alterações. Devidamente projetado, poderia servir como uma espécie de ferramenta de autodocumentação/familiarização/prevenção de erros para alguém que contribuísse com alterações de código. Mas a chave provavelmente está no design do TypeScript.

No geral, haveria um benefício de desempenho? Isso é mais difícil de determinar. Isso é mais o artista do que a tela.

Embora eu pretenda usar o TypeScript para meus próprios projetos, provavelmente estou um pouco mais inclinado a concordar com @lukeapage , principalmente porque, a menos que algum de nós aqui seja especialista em TypeScript, não tenho certeza se poderíamos fazer uso eficaz dele inicialmente.

Além disso, a mudança para o ES6 não impede o uso do TypeScript no futuro. O objetivo da Microsoft / Google é tornar o TypeScript 2.0 um superconjunto ES6, para que possamos sempre começar com ES6 / Babel e, posteriormente, adicionar tipos apropriados e alternar para o transpilador TypeScript. Minha suspeita é que o TypeScript vai "ganhar" as linguagens transpiladas, apenas porque os benefícios de tempo de compilação / preenchimento automático são muito maiores em relação ao JavaScript não tipado. Então... Acho que isso significa que acho que usar o TypeScript é provavelmente inevitável, mas isso não significa que temos que usá-lo imediatamente.

Eu gostaria de discutir uma abordagem arquitetônica diferente para Less em algum momento, mas isso é mais uma discussão tangente a isso.

Por modo digitado você quer dizer o proibir Qualquer?

Não. Apenas usando variáveis ​​tipadas em geral. Você _pode_ proibir o uso de Any em geral, mas é (pelo menos praticamente) uma má ideia porque tende a levar a muito código bloat apenas para satisfazer o sistema de digitação.

No entanto, o uso de parâmetros tipados em uma função significa que os chamadores (pelo menos os chamadores escritos em TypeScript) _devem_ respeitar o tipo fornecido. Isso significa que funções tipadas podem ser usadas para proteger a estabilidade de tipo no funcionamento interno do compilador Less quando apropriado e garantir que funções particularmente importantes sejam bem otimizadas. (Não se esqueça; os motores JS geralmente otimizam no nível da função...)

trabalho iniciado - https://github.com/less/less.js/tree/rollup

Trabalho bem legal. Germaine para a discussão, eu estava olhando o código e rapidamente me deparei:

if (typeof index === 'number') {   

AFAIK esse tipo de verificação de sanidade nunca seria necessário no TypeScript. Se o tipo de índice está sendo convertido em tempo de execução para string toda vez para fazer uma comparação de string para verificar o tipo de valor, coisas assim podem somar. No TypeScript, se houvesse uma chamada para uma função que passasse um índice, mas esse tipo às vezes não fosse um número e indexasse apenas _aceito_ um número, a função falharia no tempo de compilação devido a tipos incompatíveis, em vez de precisar para ser testado em tempo de execução, quando tais verificações são mais caras.

Por outro lado, pode ser que este seja um exemplo isolado e raro; é apenas algo que me deparei que parecia relevante.

Eu acho que a maior vantagem dos tipos explícitos é que eles permitem ferramentas mais poderosas. Encontrar todos (e apenas) lugares que chamam uma função ou a substituem é apenas um atalho de teclado. Descobrir quais funções os objetos que você tem disponíveis não dão trabalho e a refatoração é mais segura porque o compilador gera mais erros. Também torna mais fácil aprender uma nova base de código - obter uma visão geral, descobrir qual parte do código depende ou seguir o fluxo de código sem executá-lo é mais difícil em javascript do que em java (por exemplo), porque os editores tipados são mais poderosos.

Ainda não usei o TypeScript, então não sei se as ferramentas estão maduras o suficiente para fazer valer a pena. A vantagem do javascript é que todos o conhecem, o TypeScript é menos conhecido.

No geral, acho que a mudança para o TypeScript faria sentido se planejássemos algum tipo de refatoração maior ou novos recursos enormes, mas pode ser muito trabalho enquanto estamos apenas corrigindo pequenos bugs.

Acho que a mudança para o TypeScript faria sentido se planejássemos algum tipo de refatoração maior ou novos recursos enormes, mas pode ser muito trabalho enquanto estamos apenas corrigindo pequenos bugs.

Este pode ser o caso e, realmente, para ser pragmático, @lukeapage já assumiu o trabalho, então estou inclinado a dizer que ele deve fazer a decisão final neste momento. :-)

Ei, sobre isso: há algo que devemos fazer para que as pessoas saibam que a base de código está mudando? Suponho que, caso contrário, você terá conflitos de mesclagem.

não, não deve haver muitos conflitos. primeiro passo são apenas módulos es6 - não
movendo qualquer arquivo, podemos adicionar babel ou typescript de forma transparente.

Olá pessoal, como vão agora?

Eu posso trabalhar nisso. @matthew-dean Você aceitaria um pull request?

@alexlur Com certeza! Minha única preocupação é a refatoração para o branch 3.x e não obter conflitos de mesclagem. Então é melhor bifurcar/ramificar a partir daí. Além disso, desde que este problema foi escrito, agora existe uma convenção bem estabelecida de usar src/ e dist/ . No entanto, lib/ às vezes é usado como src/ , então provavelmente não há necessidade de renomear.

Também haveria uma pequena reescrita do Gruntfile para que os testes estivessem usando compilações e não lib/ . (O que o teste do navegador faz é fazer uma compilação em test/ e não dist/ . A pasta dist/ é uma tarefa Grunt especial para novos lançamentos. Ao testar, ela deve compilar para test/ ) Depois de fazer isso, contanto que os testes passem, você deve estar bem.

@matthew-dean Olá. Terminei a refatoração, mas não sei como configurar o Gruntfile para executar testes nos novos arquivos compilados.

Talvez o que eu possa fazer seja mesclar suas alterações em um branch separado e ver como integrar os testes. Eu estava apenas analisando rapidamente suas alterações. Corrija-me se estiver errado, mas at-rule é o nó assignment $#$ incorretamente? Ou o Github estava apenas atrapalhando como estava mostrando isso?

Boa captura, usei o arquivo errado.

Existe uma versão mínima do navegador / Node.js que o less.js deve suportar? O Node.js tem um suporte bastante bom para Promise (desde 0.12), enquanto o uso do navegador é geralmente para desenvolvedores que já executam as versões mais recentes do navegador.

Editar:

Less.js é compatível com todos os navegadores modernos (versões recentes do Chrome, Firefox, Safari, IE11+ e Edge)

Apenas o Internet Explorer 11 não possui Promise embutido.

@alexlur
Para a versão do Less no navegador, sugiro criar uma propriedade less.Promise e defini-la como window.Promise por padrão. E então faça Less consumir a classe Promise através de less.Promise .

Dessa forma, os usuários de navegadores modernos, bem como os usuários que têm Promise globalmente polyfilled antes de Less ser carregado, terão tudo funcionando magicamente. E os usuários que não querem - ou por qualquer motivo não têm permissão - globalmente polyfill podem fazer as coisas funcionarem com uma pequena etapa adicional. Eles precisam apenas atribuir manualmente a implementação de Promise escolhida para less.Promise antes de usar Less.

@rjgotten @alexlur Less.js já tem Promise polyfills já configurados. Não há necessidade de fazer nenhum trabalho adicional lá. A maior parte do código usa este padrão:

https://github.com/less/less.js/blob/55380d49e96a6ed561cac4d13a774830aa3c17a3/lib/less/import-manager.js#L5

No lado do Node, há esse problema ainda em aberto: https://github.com/less/less.js/issues/3121

No entanto, sem nenhum feedback e com uma quantidade bastante moderada de colaboradores, estou inclinado a dizer que o Node 4+ é o caminho a seguir por enquanto. Devemos atualizar documentos/testes para refletir isso.

@matthew-dean Deve estar pronto para ser mesclado em uma ramificação separada .

@alexlur Obrigado! Vou tentar dar uma olhada em breve. Provavelmente será na próxima semana (a menos que alguém tenha a folga de verificar).

Este problema foi marcado automaticamente como obsoleto porque não teve atividade recente. Será fechado se não ocorrer mais nenhuma atividade. Obrigado por suas contribuições.

Eu criei um fork refatorado para TypeScript.

Eu criei um fork refatorado para TypeScript.

@glixlur 😮 nossa, e todos os testes passam? E constrói um less.js idêntico em dist/ ?

@matthew-dean Ainda estou trabalhando nisso, mas minha compilação para o navegador não encontrou nenhum problema até agora como um driver diário. Tecnicamente, usar o rollup dá ao meu fork uma vantagem no desempenho, mas não tenho dados para fazer backup.

@less/core Isso deve ser investigado para ver se podemos automatizar isso para uma conversão única - https://github.com/lebab/lebab

@matthew-dean Vou enviar-lhe um pull request assim que terminar.

@glixlur Ah! Ok, em seu PR anterior , você disse que não tinha tempo para isso. Se você ainda está trabalhando nisso, 👍

@matthew-dean Vou me limitar a apenas converter para ES6 e deixar a parte do TypeScript mais tarde.

@glixlur Acho que o ES6 é provavelmente o primeiro passo mais "amigável à comunidade", então isso é perfeito. Não tenho certeza se todos estão de acordo com o TypeScript, mas definitivamente um fluxo ES6 seria ótimo.

@matthew-dean Suponho que as plataformas com suporte mais baixo são o Node 6 e o ​​IE11?

O @glixlur Appveyor está atualmente configurado para testar o Node 4. Isso tornaria as coisas mais difíceis? Idealmente, seria um Babel-transforma uma pasta src/ para (substituída) lib/ (e dist/ para o navegador) pasta(s) para distribuição para Node/browser. Então, eu diria que Babel está fazendo a maior parte do trabalho de transpilar para ES5.

Feito , mas precisa fazer os testes funcionarem. O PhantomJS está obsoleto e não tem suporte para nada após o ES5.

@glixlur Legal! Re: PhantomJS, ele realmente precisa ser substituído por algo como Chromy. Veja: https://github.com/less/less.js/issues/3240

@glixlur Além disso, isso é relacionado ao Chromy / Chrome sem cabeça: https://github.com/less/less.js/issues/3262

@glixlur Em relação ao PhantomJS - esses testes estão sendo executados na versão do navegador empacotada, que você provavelmente estaria transpilando para o ES5, correto? Por que o PhantomJS não funcionaria com o pacote de saída ES5?

@matthew-dean Sim, mas há um bug em que Symbol é usado ao executar o PhantomJS com um arquivo transpilado pelo Babel.

@glixlur Você precisa do babel-polyfill na saída transpilada. Esse é um bom indicador de que ainda não está transpilando corretamente. Veja questões como: https://github.com/babel/babel-preset-env/issues/203

@glixlur https://babeljs.io/docs/en/babel-polyfill/

@matthew-dean babel-polyfill adiciona 87,3 KB reduzidos ao arquivo de saída. Você provavelmente não quer isso.

@glixlur
Existem outras razões pelas quais você não quer babel-polyfill . Ou seja, o fato de afetar o namespace global publicando polyfills em window e modificando os protótipos de tipos nativos como Array .

Olhe para babel-runtime e o pacote babel-plugin-transform-runtime .

Além disso, a equipe do Babel está trabalhando para limitar os polyfills agrupados por transform-runtime na mesma linha que as transformações de linguagem de limites predefinidos babel-env . Mas o trabalho deles ainda não está feito e está disponível para todos. Acabaria sendo uma coisa do Babel 7, que ainda está em beta, então não é diretamente útil. Mas definitivamente desejável para o futuro.

@glixlur @rjgotten Ah. Eu deveria ter esclarecido que não sei exatamente qual solução usar re: Babel. Só que é porque Symbol é indefinido porque não é polyfilled (ponyfilled?), o que também seria no IE11. Então talvez não seja o polyfill, mas acredito que com as configurações corretas do Babel, ele deve fornecer uma definição Symbol com escopo definido. Então, talvez seja a versão min do navegador que é o problema?

com as configurações corretas do Babel, ele deve fornecer uma definição Symbol com escopo

Será mesmo.
Essas configurações equivalem a usar o plug-in transform-runtime e sua capacidade de injetar aliases para novos built-ins como Symbol , em vez de depender de babel-polyfill .

O phantomjs deve ser preterido?

Considerando que está morto?
Provavelmente sim.

@glixlur Veja: https://github.com/less/less.js/issues/3240

Conversão feita e mesclada! Veja: https://github.com/less/less-meta/issues/32

Bem, esta semana eu aprendi que Class em JavaScript NÃO é simplesmente açúcar sintático para protótipos de funções, o que causou este problema: https://github.com/less/less.js/issues/3414

Ironicamente, me deparei com a mesma coisa com outro pedaço de código não relacionado a Less, algo como 2 semanas atrás e me lembro claramente do pensamento que me ocorreu:

caramba, gostaria de saber se essa conversão do ES6 para Less causaria esse tipo de problema.

Bem: pergunta respondida, eu acho?

Eu _so_ não invejo a tempestade de usuários que despejaram seu descontentamento sobre seu trabalho, @matthew-dean. Você tem minha simpatia por ter que lidar com essa situação. :sorriso:
Felizmente, parece que ninguém foi apocalíptico e foi tratado de forma ordenada.

@rjgotten lol Quero dizer, como você pode antecipar algo assim? A coisa mais segura teria sido não converter, ou nunca usar classes, mas isso torna a base de código menos detalhada (bem, ou potencialmente o fará, há muitas oportunidades para limpeza adicional). Tecnicamente, a integração (histórica) less-loader com Less estava usando mal a API (usando um uso não documentado/sem suporte da API), então isso foi um erro da parte deles, mas eu simpatizo com as pessoas frustradas que uma versão de ponto não importante causando uma falha de compilação.

Tipo, se alguém hackear os protótipos da sua biblioteca, como você codifica defensivamente para isso??

🤷‍♂

@rjgotten

Tecnicamente, eu lancei duas versões beta após a conversão, MAS... ninguém tem menos betas em seu pipeline. Portanto, não há como testar 800.000 repositórios que se integram ao Less e executar seus testes. Com as dependências do NPM, você realmente precisa colocá-lo lá fora e ver o que acontece.

Uma coisa que poderíamos fazer no futuro é adicionar alguns menos dependentes maiores aos testes, se pudermos descobrir o que são?

A outra coisa que eu poderia ter feito é lançá-lo como uma versão principal, mas .... tecnicamente NÃO tem nenhuma alteração (intencional) de quebra, ou seja, os recursos suportados são idênticos e inclui algumas correções de bugs, então .. .. Eu não sei, isso foi complicado.

Sim. Foi complicado.

Acho que você poderia ter tentado colocar algo em uma tag .next ou algo assim e conscientizar as pessoas para testar seus pipelines de construção com isso. Mas experiências passadas indicam que esse tipo de coisa geralmente não é ouvido.

De qualquer forma, versão principal ou não, você provavelmente acabaria sendo forçado a apenas "dar uma chance" e ver o que acontece.

Mas não me entenda mal: o refator é uma coisa muito boa. Avançando, geralmente deve tirar uma boa parte da carga de manutenção.

Tipo, se alguém hackear os protótipos da sua biblioteca, como você codifica defensivamente para isso?

Você literalmente não.

É como as pessoas reclamando que seu IL emitido em tempo de execução cuidadosamente orquestrado para acessar membros privados em C# quebra em versões menores. Se você mexer com internos, você deve saber o que está comprando. :sorriso:

@rjgotten Falando em refatoração...

..... Uma das coisas que descobri ao longo do tempo na base de código Less é que há vários lugares onde há mutações leves / sutis em objetos no AST. Uma nova propriedade aqui / um método adicionado em uma instância lá, e eu admito totalmente ter feito isso às vezes com recursos em que fiz o merge, porque em JavaScript, você pode alterar o que quiser, quando quiser, seja você documentado/definido essa propriedade ou não.

Houve alguma discussão sobre se o TypeScript versus apenas o JS moderno seria a resposta. Percebi que não ter tipos ou interfaces de objetos claros torna a base de código Less às ​​vezes muito difícil de raciocinar de uma maneira que nenhuma quantidade de documentação poderia resolver ou mesmo JSDocs poderia resolver.

Eu configurei o novo pipeline para permitir o linting do TypeScript _se_ você tiver tipos apropriados no JSDoc, mas usar o JSDoc para digitar é muuuuito mais detalhado / visualmente barulhento do que o TypeScript, e há alguns recursos de digitação que o TS simplesmente não suporta apenas por meio de anotações JSDoc . Não há uma combinação de ferramentas JSDoc / ESLint que possa resolver algumas dessas coisas que o TS oferece gratuitamente.

Então, acho que tudo o que estou dizendo é que, depois de usar o TypeScript significativamente no ano passado, e tendo passado anos na base de código Less, eu diria que 95% da curva de confusão/frustração/aprendizado de descobrir como Less funciona foram evitados se os objetos tivessem tipos de tempo de compilação impostos. Muitas vezes passei muito tempo em um depurador apenas definindo pontos de interrupção e descobrindo quais são as propriedades de um objeto _realmente_, em vez de como ele é definido em um arquivo.

Por exemplo, há uma série de recursos que Less tem que, durante a avaliação, dependem da propriedade Ruleset de um nó paths . A partir deste construtor , você pode me dizer qual é a propriedade paths e que forma ela terá? (Dica: você não pode, porque não está lá.)

No TypeScript (com configurações comuns de tsconfig), isso não seria permitido. Nem compilaria. Você seria forçado a especificar a forma de paths , e exatamente o que estaria nele, o que, por sua vez, forneceria documentação clara e específica (e dicas de código) para alguém que explorasse a base de código.

Então, acho que neste ponto, deixei de pensar: "O TypeScript é algo a ser considerado" para me sentir como: "Se seu projeto público não está no TypeScript, você tem uma grande dívida técnica". Eu nunca iniciaria nenhum repositório de código aberto sem ele, porque ele inerentemente ajuda a resolver a capacidade de consumo e a manutenção. Você ainda precisa de uma documentação clara, mas pelo menos ela impõe uma codificação extremamente clara e coesa.

Isso sou apenas eu pensando sobre para onde ir a partir daqui e maneiras de evitar pontos de dor no futuro.

_( Adendo : caso não esteja claro, não estou 100% criticando o trabalho histórico de ninguém na base de código Less. tipo, "Oof, eu gostaria de não ter feito isso", ou gostaria de ter feito diferente. E certamente adicionei coisas que percebo agora que podem ter impactado negativamente a manutenção. Todo mundo fez o seu melhor.)_

@matthew-dean
Eu configurei o novo pipeline para permitir o linting do TypeScript se você tiver tipos adequados no JSDoc, mas usar o JSDoc para digitar é muito mais detalhado / visualmente barulhento do que o TypeScript, e há alguns recursos de digitação que o TS simplesmente não suporta apenas por meio de anotações JSDoc . Não há uma combinação de ferramentas JSDoc / ESLint que possa resolver algumas dessas coisas que o TS oferece gratuitamente.

Na verdade; Eu me deparei com o problema com o suporte a JSDoc sendo mais ou menos para inferência de tipos também.
Felizmente, você pode usar os arquivos de declaração .d.ts ao lado dos arquivos de origem .js , sem a necessidade de usar o TypeScript completo e exigir o compilador.

Costumava ser muito mais difícil trabalhar com arquivos de declaração, mas as versões modernas do compilador do TypeScript associam automaticamente um arquivo .d.ts lado a lado com um arquivo .js , desde que ambos sejam nomeados o mesmo.

Isso pode ser o que você está procurando.

@rjgotten Você pode explicar um pouco mais (ou link, se você conhece um bom recurso), de como isso pode funcionar bem com a base de código de Less? Como em, como você faz isso em um arquivo por nível de arquivo? Existe um arquivo $#$ .d.ts .js ? Ou você os agrupa?

Quais são as vantagens de ter um arquivo .d.ts versus apenas usar o TypeScript na fonte? Por que gastar tempo criando arquivos .d.ts em vez de apenas definir esses tipos nos arquivos?

@rjgotten Eu estava conversando com o desenvolvedor do Chevrotain hoje, e ele diz que o que ele faz é desenvolver em TS _MAS_ ele realmente gerencia um arquivo api.d.ts como uma preocupação separada. Dessa forma, quaisquer alterações de tipos nos arquivos de origem (como nós de árvore) não alteram de forma transparente/invisível a API pública sem uma alteração explícita do arquivo de tipos de api.

Em seguida, ele usa um teste com uma afirmação de que os tipos internos e os tipos de API pública correspondem -> https://github.com/SAP/chevrotain/blob/master/packages/chevrotain/test_integration/definitions/api_type_checking.ts#L1 - L2

A maneira da Chevrotain é uma boa maneira de fazer com que sua API pública não seja alterada acidentalmente. Muito robusto, se você acha que precisa desse nível de proteção. Mas também incorre em alguma sobrecarga.

Com relação ao uso de arquivos de declaração .d.ts para armazenar .js digitações:
Na verdade são os dois.

Se eles forem lado a lado, qualquer IDE que seja apoiado pelo compilador TypeScript para auto-sugestões, linting, etc. Afaik _também_ se esses scripts com digitações lado a lado forem importados de node_modules , o que é muito bom.

Você também pode colocar tipagens em um único (conjunto de) .d.ts arquivo(s) como api.d.ts e então usar JSDoc para importar os tipos declarados explicitamente. O suporte a JSDoc no TypeScript tem um sabor especial de @typedef para isso com sintaxe de importação. Por exemplo

/**
 * <strong i="17">@typedef</strong> {import("../api.d.ts").MyType } MyType
 */

Usar um único arquivo de tipagem empacotado é uma boa ideia se você tiver que levar seu pacote por uma etapa de transpilação antes da distribuição. Nesse caso, o que os usuários realmente serão require() ou import {} não serão mais os arquivos originais. Ou seja, eles não se beneficiariam de digitações lado a lado.