Rollup-plugin-typescript2: A opção tsconfig padrão "include" é substituída pelo índice do tsconfig.json original

isso torna o uso de include impossível, já que você nunca sabe quanto tempo o array ficará em tsconfig.json

Coisa interessante,
se eu mover typescript2 config include opção de tsconfigDefaults para tsconfigOverride
ele substituirá a tsconfig.json include opção original pelo índice.

ou seja, é exatamente o oposto
mas também é muito ruim

e mais uma coisa
depois de algumas investigações adicionais
Percebi que o mesmo comportamento é relevante para outras propriedades de array também

Então, já encontrei esse problema antes em https://github.com/jaredpalmer/tsdx/pull/666#discussion_r404847759 e, de acordo com esse problema, é assim que funciona a fusão profunda de _.merge . É uma fusão profunda, por isso mescla as matrizes e o índice é o único identificador da matriz. Pode ser _inesperado_, mas é uma fusão profunda, é assim que as fusões profundas funcionam.

Na verdade, ele não concatena essas propriedades, mas substitui os valores na célula do índice ,

• Em vez disso, fazer um append / concat não estaria mesclando e não daria como sobrescrever tsconfig alguma. Isso me parece um comportamento errado.
• Em vez disso, fazer uma mesclagem superficial iria apenas sobrescrever o que está nos padrões, que não tenho certeza se é o comportamento esperado, mas é semelhante a como tsconfig funciona em relação a exclude : se você adicionar um exclude , ele sobrescreve os padrões.

Eu poderia escrever um PR para fazer uma fusão superficial em apenas include e exclude , mas isso seria _bastante_ quebra de uma mudança; Não tenho ideia de como isso pode afetar todos os usuários downstream. Identifique se os usuários do TSDX esperam uma mesclagem superficial ou profunda, mas isso interromperia seu uso se esperassem profunda.

se eu mover typescript2 config include opção de tsconfigDefaults para tsconfigOverride
ele substituirá a tsconfig.json include opção original pelo índice.

ou seja, é exatamente o oposto

Sim, é assim que tsconfigOverride deve funcionar, é uma substituição.

Percebi que o mesmo comportamento é relevante para outras propriedades de array também

Sim, é assim que _.merge faz uma fusão profunda, então qualquer coisa em tsconfig que seja uma matriz tem a mesma alteração.

@ agilgur5 obrigado pela resposta!

1) Do meu ponto de vista, este comportamento torna a configuração totalmente inútil. Não podemos garantir a confiabilidade da configuração se estivermos vinculados a uma posição no array.

2) Na verdade, seria uma mudança significativa. Mas se nossa direção é alcançar o melhor DX , então devemos deixar isso claro e útil.

Eu tenho um truque em meu bolso para lidar com isso, mas parece barulhento do ponto de vista do código limpo - apenas leia tsconfig , obtenha a propriedade include e concatene isso com meu array. Parece que deveria ser mais fácil.

Minha sugestão:
1) para padrão - reúna a propriedade padrão e concatene com o tsconfig original; remova duplicatas.
2) para substituir - aplicar apenas a opção de substituição

Os padrões normalmente não se concatenam quando substituídos, eles são substituídos. E como mencionei acima, a concatenação torna _impossível_ substituir o padrão com um tsconfig . Isso soa como um comportamento errado para mim de várias maneiras, então eu o desencorajo fortemente.

Acho que todas as opções são confusas, não tenho certeza se concordo que qualquer uma dessas seja o "melhor DX". Uma mesclagem superficial é a coisa mais próxima de como tsconfig funciona com seu exclude padrão, mas isso não vem sem compensações.
Em geral, as alterações de interrupção precisam ter muito pensamento colocado nelas, é por isso que eu trouxe isso à tona - os efeitos downstream não são triviais; O TSDX também teria que liberar uma alteração importante para atualizar essa alteração.

@ agilgur5 bem, então não posso usar nem o padrão nem o override.
Causa? Não há garantia de que nenhum valor será escrito nesse índice.
Além disso, você pode contornar tudo por meio de undefined como um valor da matriz e adicionar ainda mais o valor necessário. E acontece que existe uma lacuna neste sistema? Simplesmente ótimo.

O caso:

1. Quero adicionar minhas d.ts tipificações adicionais dentro da propriedade de configuração "incluir".
2. O usuário coloca seu src dir dentro de "incluir" com outro projeto específico d.ts tipificações fora de src .

1. ['config.d.ts`]
   2. ['Src', 'some.d.ts', 'another.d.ts']
2. Resultado: ['src', 'some.d.ts', 'another.d.ts']

Como você pode ver, não há como configurar isso corretamente. Devo ler tsconfig.json, obter sua propriedade "include" e mesclar isso em ['src', 'some.d.ts', 'another.d.ts', 'config.d.ts'].
E eu acho que isso é uma sobrecarga completa.

Enquanto isso, descobri qual é o problema. Outros podem não descobrir e gastar seu precioso tempo para descobrir o que não funciona para eles.
E depois de sua primeira mensagem, já vi pelo menos 2 questões relacionadas. E isso vai continuar e continuar.

Vejo que se deixarmos tudo como está não posso usar, é uma caixa preta para mim porque não posso garantir nada.
Não há espaço para preferências pessoais "gosto" / "não gosto".
Isso pode ser usado ou não. E não pode.

Não tenho nenhum problema em reunir as opiniões de outras pessoas que estão envolvidas nisso.
E mais uma coisa, não tenho problemas para ficar com a solução atual, tenho o hack descrito acima, que estou pronto para continuar. Mas não entendo qual é o problema de tornar essa solução transparente, sem estar vinculado ao fato de que isso implicará em mudanças bruscas.

Quer dizer, você está dando sua própria preferência aqui, enquanto eu já dei várias opções diferentes. Já disse duas vezes porque essa preferência, concatenação, é fundamentalmente quebrada, igualmente não intuitiva e nem um pouco "transparente". Para repetir, a concatenação não é _só_ uma alteração significativa, ela literalmente torna impossível substituir as coisas. Vou repetir, impossível .
Ser impossível substituir com concatenação não é uma "preferência", isso é um fato.

Novamente, um "padrão" que não pode ser substituído não é um padrão, é um requisito. Alterar um "padrão" para um requisito não faz sentido e é um comportamento errado.

Você pode substituir a fusão profunda agora, você não pode substituir uma concatenação. Tornar impossível um caso de uso existente não faz sentido.

Eu também já dei uma opção alternativa duas vezes que não está fundamentalmente quebrada, que é uma mesclagem superficial. Vou repetir, você pode usar uma mesclagem superficial para resolver isso também.
Se isso é melhor, é discutível. Existem compensações para tudo.

Já contribuí aqui para corrigir bugs (sei que é _.merge porque li a base de código) e uma biblioteca que mantenho constitui uma parte significativa do uso desta biblioteca (~ 10%), estou não apenas fazendo pontos de discussão aqui ...

Sem mencionar que isso pode ser resolvido sem interromper as alterações - você pode adicionar uma nova opção para tsconfigConcat ou tsconfigDefaultShallow etc.

Dizer que há apenas uma opção e que deve ser inválida e deve tornar impossível o caso de uso existente simplesmente não é verdade.

Acho que teremos que quebrar as coisas, não importa o que façamos aqui. Para fazer com que se comporte de acordo com o espírito da documentação e dos nomes das propriedades, ele deve fazer basicamente o seguinte:

• tsconfigDefaults - este é o objeto em que tudo abaixo será profundamente mesclado
• tsconfig - este é o objeto que obtemos do typescript, depois de suas próprias importações e tudo mais. Todos os valores aqui substituem os valores em tsconfigDefaults . Todos os arrays aqui são concatenados com os arrays em tsconfigDefaults .
• tsconfigOverride - esta é a opção nuclear. Os objetos ainda são fundidos profundamente, mas os arrays aqui substituem os arrays no atacado. Portanto, se você fornecer um array de inclusão vazio aqui, o tsconfig final não terá inclusões.

Isso abrangerá todos os casos que queremos oferecer suporte (depois que os usuários fizerem as alterações apropriadas) ou estou faltando alguma coisa?

@ezolenko parece incrível e faz muito sentido usar

@ezolenko Não sei por que você tem que quebrar as coisas? Eu dei opções que já são ininterruptas.

Não tenho certeza de como o que você listou reflete "o espírito da documentação e os nomes das propriedades" porque os documentos dizem:

O objeto passado como tsconfigDefaults será mesclado com tsconfig.json carregado. A configuração final passada para o typescript será o resultado dos valores em tsconfigDefaults substituídos por valores carregados em tsconfig.json
[...]
Esta é uma fusão profunda (objetos são fundidos , matrizes são concatenadas, primitivas são substituídas , etc), aumente verbosity para 3 e procure parsed tsconfig se você obtiver algo inesperado.

Ele diz "mesclado", "substituído" e "mesclado profundo", todos significando substituir e substituir o padrão. Há uma única referência a "concatenado" que é _diferente do resto_, mas uma fusão profunda _não_ de fato concatena. 5 referências dizem uma coisa e uma 6ª está incorreta. Para mim, isso soa como a 6ª referência que está incorreta deve ser corrigida, não as 5 corretas alteradas para a 6ª incorreta.

lodash é o padrão de fato e sua definição de mesclagem _não_ deve ser concatenada. A definição dos padrões é que eles são substituídos quando você define o mesmo valor de propriedade, _não_ concatenado:

_.defaults({ a: ['a'] }, { a: ['b', 'c'] });
// => {a: ['a']}
_.defaultsDeep({ a: ['a'] }, { a: ['b', 'c'] });
// => {a: ['a', 'c']}

Se você gostaria de adicionar uma opção de concatenação, acho que deveria ser uma configuração separada, porque não corresponde a 5+ referências nos documentos e porque isso simplesmente não é o que os padrões significam, nem na definição nem no uso em qualquer biblioteca.

Ele também quebra a simetria com tsconfigOverride , bem como com seus próprios documentos:

• tsconfigOverride : {}
  Veja tsconfigDefaults .

Espero que os padrões sejam substituídos, essa é a definição, fazê-los concatenar é incrivelmente não intuitivo. Uma mesclagem profunda pode não ser intuitiva para matrizes, mas os documentos dizem claramente que é uma mesclagem profunda e compreendi rapidamente que esse era o problema porque os índices eram relevantes. Eu também não relatei um bug porque é o que dizem os documentos e até mesmo um link para deep merge - esse é o comportamento pretendido, não um bug.

Como eu disse, mesclar superficialmente os arrays pode ser mais intuitivo, pois é assim que tsconfig _self_ realmente funciona. Como vinculei acima, tsconfig _itself_ não concatena quando você adiciona um exclude , ele substitui o exclude .

Portanto, concatenar não corresponde a 5+ referências nos documentos, a definição de mesclagem, a definição de padrões, nem o próprio comportamento de tsconfig . E quebra a simetria e apresenta outras opções. Não tenho certeza de como isso é intuitivo.

E como eu disse várias vezes, torná-la uma concatenação muito pouco intuitiva em vez de substituir torna certos casos de uso _impossíveis_ . Aqui está o uso do TSDX:

https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

A intenção é que, se você adicionar seus próprios exclude , ele substituirá os padrões que definimos. Os padrões são aplicados apenas se você não definir o nome da propriedade, assim como qualquer outro nome de propriedade (novamente, essa é a definição dos padrões e como os padrões funcionam em todas as bibliotecas).

Se você alterasse isso para concatenar, então o usuário agora não tem como sobrescrever nosso exclude padrão, é _impossível_ para eles sobrescrever o padrão. Enviamos tsconfig padrão exclude também, então isso também torna _impossível_ substituir o tsconfig , embora tsconfig _itself_ permita que você faça naquela.

Não sei por que estou falando como um disco quebrado aqui, repetindo _definições existentes_ e _ uso existente_ em todo o ecossistema _.

@ agilgur5

E como eu disse várias vezes, tornando-se uma concatenação muito pouco intuitiva em vez de substituir
torna impossíveis certos casos de uso. Aqui está o uso do TSDX:
https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

Essa configuração pode ser interrompida facilmente e não entendo por que isso não é óbvio para você. Não quero que minha biblioteca seja frágil e é por isso que criei esse problema.

o engraçado é que @ezolenko e eu já propusemos uma solução que ajudará a proteger, incluindo TSDX, mas você ainda resiste.

Os padrões são aplicados apenas se você não tiver definido o nome da propriedade

Eu concordo com o comportamento

impossível para eles substituir o padrão

A questão é: por que o usuário deveria ter acesso ao que o autor da biblioteca proibiu?

Devemos aproveitar a configuração tsconfig que não pode ser substituída, mas, ao mesmo tempo, precisamos dar a oportunidade de expandir nossas predefinições. E este é o ponto principal.

A solução está apenas no design da nova API.

Essa configuração pode ser interrompida facilmente e não entendo por que isso não é óbvio para você. Não quero que minha biblioteca seja frágil e é por isso que criei esse problema.

Você está tirando da minha boca palavras que eu não disse nem remotamente. Eu não disse que não pode e nem disse que não era frágil. Acabei de dizer que _sua_ solução não corresponde a nenhuma _definição existente_ nem _utilização existente_ em _todo o ecossistema_ de padrões nem aos próprios documentos. Quebrar toda a definição de inadimplência é um comportamento claramente errado.
Como já disse várias vezes, minha sugestão foi mesclar matrizes rasas, ou seja, tsconfig substitui tsconfigDefaults como faz para todas as propriedades que não sejam de matriz e como tsconfig _self_ funciona .
Como eu disse várias vezes, isso pode ser feito com uma alteração interruptiva ou uma alteração ininterrupta.

Por favor, não tire as palavras da minha boca. Já me repeti várias vezes, por favor, leia as coisas reais que escrevi em vez de inventar coisas.

A questão é: por que o usuário deveria ter acesso ao que o autor da biblioteca proibiu?

tsconfig não proibiu isso, TSDX não proibiu isso e rollup-plugin-typescript2 também não proibiu, então não sei a que você está se referindo.

Devemos aproveitar a configuração tsconfig que não pode ser substituída, mas, ao mesmo tempo, precisamos dar a oportunidade de expandir nossas predefinições. E este é o ponto principal.

A solução está apenas no design da nova API.

Sim, você pode adicionar uma opção tsconfigConcat para isso, e isso seria uma "nova API". Quebrar a API atual reinventando toda a definição de padrão cria todo um conjunto de novos problemas e um novo comportamento não intuitivo. Exceto enquanto uma fusão profunda pode não ser intuitiva para matrizes, ainda é um comportamento _correto_. Uma concatenação é simplesmente um comportamento errado, porque não é isso que o padrão significa.

A tsconfigConcat resolveria seu caso de uso e é mais intuitivo porque literalmente tem concat no nome e é exatamente o que faz.
Alterar tsconfigDefaults para significar "concatenação" não é porque isso, pela quinta vez, _não é o que o padrão significa_.

default = \ = concatenação. Essa não é minha opinião, essa é a definição.

@ agilgur5 desculpe, mas você não pode ser levado a sério.
cada frase sua é polêmica, estou cansado disso.

Eu simplesmente argumento que a API atual não permite nenhum trabalho adequado com ela, e esta é a razão para mudá-la.
Eu não vou continuar mais com isso.

Bem, eu não tirei palavras da boca das pessoas, não li suas palavras reais, inventei coisas, ataquei o personagem de um contribuidor, forneci 0 links, dei 0 alternativas e considerei apenas uma opção e nenhuma outra, que foi você .

Se você gostaria de atacar um contribuidor que está apenas tentando ser útil e está dando definições reais, casos de uso reais e alternativas reais, acho que essa é a sua prerrogativa: encolher os ombros:

Eu acho que estava com a impressão de que o lodash merge iria de fato mesclar arrays (intercalá-los ou algo assim) quando eu estava escrevendo essa parte. Ou eu nem estava prestando atenção no que acontece com as matrizes. Visto que ele aparentemente sobrescreve o conteúdo de arrays usando índices como nomes de elementos (certo? Essa coisa de javascript sobre arrays originalmente não são arrays verdadeiros, mas sim dicionários que por acaso têm números para chaves?), Nossa documentação no momento se encontra.

Idealmente, as opções de tsconfigs default / main / override devem permitir a personalização de todos os parâmetros, tanto valores escalares quanto matrizes, da mesma maneira nada surpreendente. A maneira Lodash de substituir elementos de array com base no índice tem uma grande desvantagem - você não pode criar arrays esparsos literais (talvez array de preenchimento com um monte de undefined s?). Isso significa que a configuração de rollup deve ser construída dinamicamente e o tsconfig, sendo um arquivo json, não pode fazer nada disso.

Mesmo com matrizes esparsas literais, substituir elementos com base no índice é muito frágil.

Por outro lado, a concatenação é surpreendente, se nada mais geralmente se comporta dessa maneira. E sozinho não permite a remoção de valores anteriores.

Alternar entre concatenar e substituir como propus originalmente é duplamente surpreendente.

Alterar ambas as mesclagens para substituir os arrays no atacado como @ agilgur5 proposto é provavelmente a opção menos surpreendente, pois permitirá a remoção de valores, ao custo de ter que repetir os valores que se deseja manter. No entanto, ainda é uma mudança significativa e as pessoas terão que reescrever suas configurações para isso (consulte https://xkcd.com/1172/).

Podemos alterar o comportamento dessas opções ou criar um novo conjunto e descontinuar as opções existentes com um aviso.

(desculpe se eu perdi um ponto importante em algum lugar, eu apenas pulei o tópico inteiro)

@ezolenko eu vejo a próxima maneira

Vejamos a situação e a motivação:
O desenvolvedor deseja adicionar algumas configurações necessárias para o texto digitado por meio do plug-in de rollup.
Nesse caso, não devemos impedir que o desenvolvedor adicione configurações com segurança e não devemos perder nenhuma outra configuração ao mesclar a configuração e as configurações de rollup.

O que isso nos diz? Vamos começar pela semântica:

Como eu disse antes

Eu concordo com o comportamento padrão. Faz sentido aplicar o padrão de configuração apenas quando tsconfig não tem propriedades correspondentes ...

Podemos redesenhar essa coisa completamente.

Minhas sugestões são:

1. Aplique as propriedades tsconfigDefaults quando o tsconfig não tiver propriedades correspondentes.
2. tsconfigOverride deve cuidar disso.
   2.1 Deve funcionar como antes com valores escalares.
   2.2 Deve concatenar as propriedades do array. (provavelmente isso não deve quebrar nada e deve atender à motivação da configuração)

Eu só estou tentando evitar a terceira opção rpt2 adicional, porque vai complicar esta API em pelo menos 50% e qualquer desenvolvedor deixará de entender isso.

@ agilgur5 É maravilhoso que a realidade e as palavras que você diz não sejam a mesma coisa.

Além disso, graças ao e-mail de notificação, li a mensagem original, e não editei 8 vezes, para parecer melhor aos olhos das pessoas.
Ninguém queria te atacar, aliás, ninguém o fez.
Você simplesmente foi convidado a parar de ser agressivo e de escrever discursos contraditórios neste tópico.

• 0 links - gastei muito tempo para entender o problema, descrevê-lo completamente, dar exemplos e até mesmo fazer capturas de tela. E também, eu até estudei seu TSDX, e disse que sua configuração é frágil, porque eu verifiquei. E o mais importante, não fiquei em silêncio, mas criei esse problema para agravar o problema para aqueles que se deparam com isso.
• 0 alternativas - leia com atenção. Comecei a oferecer soluções desde a primeira mensagem.
• tirando palavras - acalme-se e pare de ser narcisista pelo menos neste tópico, é desagradável para mim trabalhar assim.

@maktarsis como, em sua abordagem, o dev seria capaz de remover entradas de inclusão ou exclusão de tsconfig? O cenário é: você tem um tsconfig.json que é usado em outro lugar, deseja usá-lo no rollup sem tocar no próprio json, mas deseja remover uma linha do array excludes por algum motivo.

@ezolenko , entendi o seu

Naturalmente, conforme discutido acima, isso não será possível.
Mas estamos falando sobre possibilidades ao invés de motivação.

Ainda não vejo situações em que precisamos reescrever a exclusão.
No entanto, sou de opinião que não precisamos sobrescrever o "exclude" do dev. Em outras palavras, não consigo imaginar por quê.
É necessário entender o motivo de "por algum motivo".

Se você quiser ter essa possibilidade em qualquer caso, precisará fornecer uma API adicional para concatenação.
Mas, como você pode entender, acho que pode ser não reclamado e simplesmente desnecessário.
A exclusão de algo de "excluir" pode não ser necessária, mas se formos por outro caminho, complicaremos o entendimento da configuração.

Precisamos de ambos, adicionando algo ao array que não está lá e removendo algo dele. Com a mesclagem superficial, tanto a adição quanto a remoção são feitas através da replicação de toda a matriz (com alterações) em um nível superior. Não é muito conveniente, mas pode ser usado.

Este também é o caso de "esModuleInterop": true que fez minha biblioteca não funcionar em alguns ambientes.

Opção de compilador inútil em config.json:

{
   ...
  "compilerOptions": {
       ...
      "esModuleInterop": true,
  },
}

Opção de compilador útil em rollup-config:

typescript({
    useTsconfigDeclarationDir: true,
    tsconfigOverride: {
      esModuleInterop: true,
    },
  }),

A primeira sugestão de

Aplique as propriedades tsconfigDefaults quando o tsconfig original não tiver propriedades correspondentes.

^ o comentário acima não parece relacionado, pois não é para include ou matrizes. A "sugestão" mencionada é o que tsconfigDefaults já faz.
Além disso, eu e o TSDX, usamos esModuleInterop pesadamente, então sei que funciona em tsconfig.json , não tenho certeza do que esse comentário deveria significar. A configuração postada também está faltando compilerOptions , deveria ser:

js typescript({ useTsconfigDeclarationDir: true, tsconfigOverride: { compilerOptions: { esModuleInterop: true, }, }, }),

Mas isso substituiria e funcionaria conforme o planejado.

Observando aqui que a mesclagem superficial foi mencionada anteriormente neste repo algumas vezes: # 86 (que menciona o comportamento de mesclagem superficial do TS como eu fiz aqui), https://github.com/ezolenko/rollup-plugin-typescript2/issues/72 #issuecomment -383242460 e https://github.com/ezolenko/rollup-plugin-typescript2/issues/208#issuecomment -594237841