Definitelytyped: [@ types / styled-components] Problemas de desempenho no compilador

Isso também acontece com o texto datilografado 3.3?

Eu experimentei o mesmo problema

package.json

devDependency

"@babel/core": "^7.4.0",
"@babel/plugin-proposal-class-properties": "^7.4.0",
"@babel/plugin-syntax-dynamic-import": "^7.2.0",
"@babel/plugin-transform-async-to-generator": "^7.4.0",
"@babel/preset-env": "^7.4.2",
"@babel/preset-react": "^7.0.0",
"@babel/preset-typescript": "^7.3.3",
"babel-jest": "^24.5.0",
"babel-loader": "^8.0.5",
"babel-plugin-styled-components": "^1.10.0",
"css-loader": "^2.1.1",
"file-loader": "^3.0.1",
"html-webpack-plugin": "^3.2.0",
"jest": "^24.5.0",
"mini-css-extract-plugin": "^0.5.0",
"node-sass": "^4.11.0",
"react-svg-loader": "^2.1.0",
"regenerator-runtime": "^0.13.2",
"sass-loader": "^7.1.0",
"style-loader": "^0.23.1",
"ts-loader": "^5.3.3",
"typescript-tslint-plugin": "^0.3.1",
"webpack": "^4.29.6",
"webpack-cli": "^3.3.0",
"webpack-dev-server": "^3.2.1"

dependência

"@babel/polyfill": "^7.4.0",
"@loadable/component": "^5.7.0",
"@types/loadable__component": "^5.6.0",
"@types/react": "^16.8.10",
"@types/react-dom": "^16.8.3",
"@types/react-router-dom": "^4.3.1",
"@types/styled-components": "4.1.5",
"axios": "^0.18.0",
"react": "^16.8.6",
"react-dom": "^16.8.6",
"react-router": "^5.0.0",
"react-router-dom": "^5.0.0",
"styled-components": "^4.2.0",
"styled-normalize": "^8.0.6",
"typescript": "^3.4.1"

Meu problema é que parece que webpack & webpack-dev-server não podem analisar @ types / styled-components. Porque quando usamos apenas componentes estilizados, não havia problema. Isso sempre acontece ao usar @ types / [email protected] ao mesmo tempo.

Antes de ver o problema do @voliva , encontrei o problema do loop infinito do webpack porque ele usa 100% do recurso cpu.

Depois de alterar a versão de @ types / styled-compoents para 4.1.5, parece que está tudo ok.

@ eps1lon : Não, o 3.4.0-dev.20190226 .

Usando o repositório de seed da OmitU , adicionado ao @ types / styled-components versão 4.1.1. Aqui está sua definição :

type OmitU<T, K extends keyof T> = T extends any ? PickU<T, Exclude<keyof T, K>> : never;

E aqui estão os dois lugares em que OmitU é usado em index.d.ts :

Definição de WithOptionalTheme

type WithOptionalTheme<P extends { theme?: T }, T> = OmitU<P, "theme"> & {
    theme?: T;
};

Uso de WithOptionalTheme (na definição de StyledComponentProps )

WithOptionalTheme<
    OmitU<
        ReactDefaultizedProps<
            C,
            React.ComponentPropsWithRef<C>
        > & O,
        A
    > & Partial<PickU<React.ComponentPropsWithRef<C> & O, A>>,
    T
>

Algo sobre o mapeamento OmitU distribuído por união sobre outro OmitU parece estar atrapalhando o compilador. Se uma ou ambas as instâncias forem substituídas por um Omit normal que não é distribuído entre os sindicatos, o tempo de compilação é reduzido para 10 segundos razoáveis ​​ou mais sob o texto datilografado 3.4.1.

(Observe que o tipo ReactDefaultizedProps também faz referência a PickU , o que pode ajudar a explicar os tempos de execução especialmente longos na segunda linha da tabela abaixo.)

Para testar isso, troquei um ou ambos os OmitU s distribuídos por um dos seguintes:

type OmitPickU<T, K extends keyof T> = PickU<T, Exclude<keyof T, K>>;
type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

Aqui está time yarn tsc executado contra o texto datilografado 3.4.1 , 3.4.0-dev.2019 0226 e a versão anterior imediata, 3.4.0-dev.2019 0223 :

| WithOptionalTheme definição | WithOptionalTheme uso | datilografado 3.4.1 | datilografado 3.4.0-dev.20190226 | datilografado 3.4.0-dev.20190223 |
| --- | --- | --- | --- | --- |
| OmitU | OmitU | 1m28.984s | 0m55.853s | 0m6.031s |
| OmitU | OmitPickU | 2m49.492s | 1m49.457s | 0m5.961s |
| OmitPickU | OmitU | 1m10.313s | 0m35.278s | 0m6.125s |
| OmitPickU | OmitPickU | 0m10.501s | 0m6.947s | 0m6.055s |
| OmitU | Omit | 0m9.611s | 0m6.781s | 0m6.102s |
| Omit | OmitU | 0m10.471s | 0m7.451s | ... etc |
| OmitPickU | Omit | 0m9.654s | 0m6.796s | |
| Omit | OmitPickU | 0m8.990s | 0m6.485s | |
| Omit | Omit | 0m9.730s | 0m6.815s | |

Os tempos de execução para datilografado 3.3.3 e 3.3.4000 são consistentes com 3.4.0-dev.20190223 - cerca de 6 segundos em toda a linha.

Não estou familiarizado o suficiente com componentes estilizados para propor uma solução, mas espero que esses dados ajudem!

Posso confirmar que tenho o mesmo problema. Fazer o downgrade de @ types / styled-components para 4.1.5 também funcionou para mim. Estou no texto datilografado 3.4.1

@michsa Eu esperava alguma redução, mas não 10x. Uma vez que isso foi introduzido no datilografado 3.4, você poderia abrir um problema no repositório datilografado também? Gostaria de ter certeza de que não reverteremos uma correção de bug se for uma regressão que deve ser corrigida no texto digitado.

Lamento, mas inicialmente não pesquisei no github do typescript, encontrei o problema que eles estão investigando: https://github.com/Microsoft/TypeScript/issues/30663

@weswigham @RyanCavanaugh Podemos dar uma olhada em publicar rapidamente uma reversão para os tipos de componentes estilizados que não têm os problemas de desempenho em 3.4.

Com o lançamento do VS Code 1.33, muitos usuários de js farão o download dos tipos com bug por meio da aquisição automática de tipo. Assim que isso acontecer, para sair do mau estado, acredito que você tenha que limpar o cache de aquisição automática de tipo ou instalar o @types/styled-components fixo. Nenhuma das experiências é boa para usuários js. Quanto mais tempo as digitações de baixo desempenho são a última versão publicada, mais usuários serão afetados (o que é uma experiência ruim para eles e muito trabalho extra para nós também)

Parece que ainda pode ser um problema com @ types / styled-components 4.1.19 e TS 3.6.3. Conclusão do TS e destaque de erro levando de 5 a 10 + segundos no macbook pro 15 i7 de 2018. É preciso fazer mais investigações.

Erm, o OP está falando sobre compilações dos anos 90 (um salto de 9x no tempo a partir da versão anterior dos componentes estilizados), visto que ambas as versões posteriores do TS têm mitigações no lugar e as versões posteriores dos componentes estilizados foram simplificadas para não ter tanto desempenho problemas, 5-10s é talvez apenas o seu projeto e deps se comportando normalmente.

Espero que não! É frustrantemente lento agora, quando não estava no passado. Vou analisá-lo com mais detalhes e relatar aqui se ele parece estar relacionado a esse problema.

Meu VSCde está inutilizável (os erros ts aparecem e desaparecem após alguns segundos, em vez de instantaneamente) assim que adiciono @ types / styled-components.

Estou usando o TS 3.6.4 e os tipos 4.1.20.

@sregg vai culpar este PR que reverteu a mitigação em @types/styled-components : https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323

(E reverter para v 4.1.19 para corrigir o problema localmente)

@sregg vai culpar este PR que reverteu a mitigação em @types/styled-components : # 39323

@ typescript-bot reúne métricas de desempenho para “avaliar se [PRs] pode afetar negativamente os tempos de compilação ou a capacidade de resposta do editor”. Em PR 39323, @ typescript-bot concluiu “Parece que nada mudou muito.” .

@sregg , você consegue pensar em uma razão pela qual as métricas existentes do @typecript-bot deixariam de destacar o problema de desempenho do editor que você observa?

(Boxe: “vá culpar este PR” não é uma sugestão construtiva, @weswigham. Por favor, seja construtivo.)

Aqui está algum contexto adicional:

@sregg relatou baixo desempenho ao usar TypeScript 3.6.4: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/34391#issuecomment -548701239

Mas, pela resposta de @ weswigham em https://github.com/microsoft/TypeScript/issues/30663#issuecomment -507406245, entendi que as versões do TypeScript ≥3.5 não incorreriam mais na penalidade de desempenho que https://github.com/DefinitelyTyped / DefinitelyTyped / pull / 34499 foi mesclado para evitar.

Então, com esse entendimento, optei por (mais ou menos) reverter https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34499 , via https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323.

As métricas de desempenho do bot são baseadas no que está nos testes e, infelizmente, os testes de componentes estilizados estão muito longe de um aplicativo real, tanto em tamanho quanto em uso (complexo). Ele está fazendo o melhor que pode com o que tem, mas nem sempre encontra _todos_ os problemas de desempenho.

(Barra lateral: "culpa" no sentido "git" - por favor, não se ofenda ~)

Isso faz sentido, obrigado @weswigham!

Até que possamos pegar essa regressão de desempenho nos testes, acho que o melhor curso de ação é reverter PR https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323 , então abri PR https://github.com / DefinitelyTyped / DefinitelyTyped / pull / 40095 para fazer isso.

Na próxima semana, vou trabalhar para adicionar um teste com base nos relatórios (por exemplo, https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323#issuecomment-549015652) que foram compartilhados. Assim que estiver funcionando, podemos avaliar (ex ante) outras soluções semelhantes a https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323.

@smockle , você tentou executar a versão mais recente (4.4.2)? Parece que o bug de desempenho está de volta, fazer o downgrade para 4.1.19 ajuda.

UPD: o mesmo com as tipificações sc v5.0.1

@sregg
Eu também!!!

Meu VSCode (* na verdade TS-SERVER) está mais lento do que antes. depois de usar componentes estilizados.
"@types/styled-components": "^5.1.0", "styled-components": "^5.1.1" "typescript": "^3.9.5"

Depois de fazer o downgrade do TS de 3.9.X para 3.8.3, o desempenho voltou ao normal para mim. Usando "@types/styled-components": "^5.1.0" e "styled-components": "^5.1.1" .

Obrigado @joaopaulobdac , tenho trabalhado em um projeto que é substancialmente mais lento na avaliação da digitação do que o outro, e demorei muito para perceber que os componentes estilizados eram os culpados. Sua correção foi feita por mim. Não parecia estar usando nenhum dos recursos 3,9x do texto datilografado, então foi uma mudança bastante indolor!

Devemos criar um novo problema então? Não atualizar é apenas uma solução de curto prazo.

Estou tendo o mesmo problema com o último junho de 2020 (versão 1.47) e "@ types / styled-components": "^ 5.1.1"

Usar o typescript 3.9.3 com a versão dos tipos de componentes estilizados 5.1.1 destrói absolutamente o desempenho do meu servidor TS VSCode. É absolutamente inutilizável: D Fazer o downgrade para o texto datilografado 3.8.3 parece restaurar pelo menos parte do desempenho, mas isso realmente poderia exigir um pouco mais de atenção.

@RyanCavanaugh reabrir?

Pode confirmar, tendo o mesmo problema.

Mesmo aqui, vale a pena reabrir!

Confirmo que meu VSCode começou a engasgar.

Acabei removendo os componentes estilizados, mas de qualquer forma não trouxe muitos benefícios em reagir nativo. Objetos JS simples e antigos com operadores de propagação e estilos embutidos funcionam muito bem sem problemas de desempenho de TS, IMO acaba sendo mais fácil de ler o código do que com componentes estilizados de qualquer maneira, pelo menos no RN.

Estou experimentando o inferno no paraíso CSS-in-JS quando estou codificando com VSCode.

@AndrewMorsillo @hilezir Mudei de componentes estilizados para styletron, usando o TS 4. O desempenho no styletron é muito melhor tanto no vscode quanto no navegador. Mas eu não sei sobre o estiletron no React Native.

@AndrewMorsillo @hilezir Mudei de componentes estilizados para styletron, usando o TS 4. O desempenho no styletron é muito melhor tanto no vscode quanto no navegador. Mas eu não sei sobre o estiletron no React Native.

É tarde demais para fazermos essa mudança, mas nunca ouvi falar do styletron e definitivamente gosto mais da aparência dele do que dos componentes estilizados.

Haverá um novo problema ou será reaberto? Ainda existem grandes problemas de desempenho com @ types / styled-components 5.1.2 e TS 3.9.7

Passei um dia inteiro tentando descobrir como acelerar o VSCode e _finalmente_ descobri que era @types/styled-components . Quando está instalado, apenas digitar qualquer coisa no editor faria com que tsserver.js (conforme mostrado pelo VSCode Process Explorer) atingisse mais de 100% da CPU e aumentasse sem limites na memória. Simplesmente removendo @types/styled-components consertou isso.

Eu estava usando o TypeScript 4.0.3 e @types/styled-components 5.1.3.

alguém pode sugerir uma alternativa melhor para componentes estilizados. meu vscode congela completamente.

alguém pode sugerir uma alternativa melhor para componentes estilizados. meu vscode congela completamente.

tente isso?

1. https://material-ui.com/styles/basics/#material -ui-styles

2. https://emotion.sh/docs/styled#styling -elements-and-components

Na verdade, há uma solicitação pull aberta para melhorar o desempenho dos tipos styled-components ': https://github.com/DefinitelyTyped/DefinitelyTyped/pull/46510.