Definitelytyped: [@types/styled-components] Problèmes de performances sur le compilateur

Est-ce que cela se produit également avec le tapuscrit 3.3 ?

j'ai connu le même problème

package.json

devDépendance

"@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"

dépendance

"@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"

Mon problème est qu'il semble que webpack & webpack-dev-server ne puisse pas analyser @types/styled-components. Parce que lorsque vous n'utilisez que des composants stylisés, il n'y avait pas de problème. Cela arrive toujours lorsque vous utilisez @types/ styled - 4.1.12 en même temps.

Avant de voir le problème de @voliva , j'ai trouvé un problème de boucle infinie de webpack car il utilise 100% des ressources cpu.

Après avoir changé la version de @types/styled-compoents en 4.1.5, il semble que tout va bien.

@eps1lon : Non, le tapuscrit 3.3 est bien ; en particulier, il semble que le problème commence sous la version 3.4.0-dev.20190226 .

En utilisant le dépôt de semences de OmitU , ajoutée dans la version 4.1.1 de @types/styled-components. Voici sa définition :

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

Et voici les deux endroits où OmitU est utilisé dans index.d.ts :

Définition de WithOptionalTheme

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

Utilisation de WithOptionalTheme (dans la définition de StyledComponentProps )

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

Quelque chose à propos du mappage de OmitU distribué par l'union sur un autre OmitU semble faire trébucher le compilateur. Si l'une ou les deux de ces instances sont remplacées par un Omit régulier qui ne se répartit pas sur les unions, le temps de compilation est réduit à environ 10 secondes environ sous le script dactylographié 3.4.1.

(Notez que le type ReactDefaultizedProps également référence à PickU , ce qui peut aider à expliquer les temps d'exécution particulièrement longs dans la deuxième ligne du tableau ci-dessous.)

Pour tester cela, j'ai remplacé l'un ou les deux des OmitU distribués par l'un des éléments suivants :

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>>;

Voici time yarn tsc exécuté contre typescript 3.4.1 , 3.4.0-dev.2019 0226 , et la version précédente immédiate, 3.4.0-dev.2019 0223 :

| WithOptionalTheme définition | WithOptionalTheme utilisation | dactylographié 3.4.1 | tapuscrit 3.4.0-dev.20190226 | tapuscrit 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 | |

Les temps d'exécution pour le typescript 3.3.3 et 3.3.4000 sont cohérents avec 3.4.0-dev.20190223 - environ 6 secondes dans l'ensemble.

Je ne connais pas assez les composants stylisés pour proposer une solution, mais j'espère que ces données vous seront utiles !

Je peux confirmer que j'ai le même problème. La rétrogradation de @types/styled-components vers la 4.1.5 a également fonctionné pour moi. Je suis sur tapuscrit 3.4.1

@michsa Je m'attendais à une réduction mais pas à un 10x. Étant donné que cela a été introduit dans Typescript 3.4, pourriez-vous également ouvrir un problème dans le référentiel Typescript ? Je voudrais m'assurer que nous n'annulons pas un correctif de bogue s'il s'agit d'une régression qui devrait être corrigée en tapuscrit.

Désolé, je n'ai pas cherché au départ dans le github de tapuscrit, j'ai trouvé ce problème qu'ils étudient actuellement : https://github.com/Microsoft/TypeScript/issues/30663

@weswigham @RyanCavanaugh Pouvons-nous s'il vous plaît envisager de publier rapidement un retour aux types de composants stylisés qui n'ont pas les problèmes de performances sur 3.4.

Avec la version VS Code 1.33, de nombreux utilisateurs de js vont télécharger les types buggés via l'acquisition de type automatique. Une fois que cela se produit, pour sortir du mauvais état, je pense que vous devez soit vider votre cache d'acquisition de type automatique, soit installer le correctif @types/styled-components . Les utilisateurs de js ne sont pas non plus de bonnes expériences. Plus les frappes peu performantes sont longues dans la dernière version publiée, plus il y aura d'utilisateurs qui seront affectés (ce qui est une mauvaise expérience pour eux et beaucoup de travail supplémentaire pour nous aussi)

Cela semble être toujours un problème avec @types/styled-components 4.1.19 et TS 3.6.3. L'achèvement du TS et la mise en évidence des erreurs prennent 5 à 10 secondes et plus sur le macbook pro 15 i7 2018. Besoin de faire plus d'enquête.

Euh, l'OP parle de compilations des années 90 (un saut dans le temps de 9 fois par rapport à la version précédente des composants stylisés), étant donné que les deux versions ultérieures de TS ont des atténuations en place et que la version ultérieure des composants stylisés a été simplifiée pour ne pas avoir autant de perf problèmes, 5-10s est peut-être juste votre projet et les deps se comportent normalement.

J'espère que non! C'est frustrant de lenteur maintenant alors que ce ne l'était pas dans le passé. Je vais approfondir la question et faire rapport ici si cela semble être lié à ce problème.

Mon VSCde est inutilisable (ses erreurs apparaissent et disparaissent après quelques secondes au lieu d'être instantanément) dès que j'ajoute @types/styled-components.

J'utilise TS 3.6.4 et les types 4.1.20.

@sregg va blâmer ce PR qui a annulé l'atténuation dans @types/styled-components : https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323

(Et revenez à v 4.1.19 pour résoudre le problème localement)

@sregg va blâmer ce PR qui a annulé l'atténuation dans @types/styled-components : #39323

@typescript-bot rassemble des métriques de performances pour "évaluer si [PRs] pourrait affecter négativement les temps de compilation ou la réactivité de l'éditeur". Dans PR 39323, @typescript-bot a conclu « On dirait que rien n'a trop changé. » .

@sregg , pouvez-vous penser à une raison pour laquelle les métriques existantes de @typescript-bot échoueraient à mettre en évidence le problème de performance de l'éditeur que vous observez ?

(Encadré : "allez blâmer ce PR" n'est pas une suggestion constructive, @weswigham. Soyez constructif.)

Voici un contexte supplémentaire :

@sregg a signalé des performances médiocres lors de l'utilisation de TypeScript 3.6.4 : https://github.com/DefinitelyTyped/DefinitelyTyped/issues/34391#issuecomment -548701239

Mais d'après la réponse de @weswigham dans https://github.com/microsoft/TypeScript/issues/30663#issuecomment -507406245, j'ai compris que les versions TypeScript ≥3.5 n'entraîneraient plus la pénalité de performances que https://github.com/DefinitelyTyped /DefinitelyTyped/pull/34499 a été fusionné pour éviter.

Donc, avec cette compréhension, j'ai choisi de revenir (plus ou moins) à https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34499 , via https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323.

Les métriques de performances du bot sont basées sur ce qu'il y a dans les tests et, malheureusement, les tests de composants stylisés sont assez loin d'une vraie application, à la fois en taille et en utilisation (complexe). Il fait de son mieux avec ce qu'il a, mais il ne trouve pas toujours tous les problèmes de performances.

(Barre latérale : "blâmer" dans le sens "git" - s'il vous plaît ne vous offensez pas ~)

C'est logique, merci @weswigham !

Jusqu'à ce que nous puissions détecter cette régression des performances dans les tests, je pense que le meilleur plan d'action est de rétablir PR https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323 , j'ai donc ouvert PR https://github.com /DefinitelyTyped/DefinitelyTyped/pull/40095 pour le faire.

La semaine prochaine, je travaillerai pour ajouter un test basé sur les rapports (par exemple https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323#issuecomment-549015652) qui ont été partagés. Une fois que cela fonctionne, nous pouvons (ex ante) évaluer d'autres solutions similaires à https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323.

@smockle avez-vous essayé d'exécuter la dernière version (4.4.2) ? On dirait que le bug de performances est de retour, une rétrogradation vers 4.1.19 aide.

UPD : Idem avec les typages sc v5.0.1

@sregg
Moi aussi!!!

Mon VSCode (*En fait TS-SERVER) est plus lent qu'avant. après avoir utilisé des composants stylisés.
"@types/styled-components": "^5.1.0", "styled-components": "^5.1.1" "typescript": "^3.9.5"

Après avoir rétrogradé TS de 3.9.X à 3.8.3, les performances sont revenues à la normale pour moi. En utilisant "@types/styled-components": "^5.1.0" et "styled-components": "^5.1.1" .

Merci @joaopaulobdac , j'ai travaillé sur un projet qui est considérablement plus lent à évaluer dactylographié que l'autre, et il m'a fallu tellement de temps pour réaliser que Styled Components était le coupable. Votre solution est faite pour moi. Ne semblait utiliser aucune des fonctionnalités 3.9x de tapuscrit, donc c'était un commutateur assez indolore !

Doit-on alors créer un nouveau problème ? Ne pas mettre à niveau n'est qu'une solution à court terme.

Je rencontre le même problème avec la dernière version de juin 2020 (version 1.47) et "@types/styled-components": "^5.1.1"

L'utilisation du typescript 3.9.3 avec la version des types de composants stylisés 5.1.1 détruit absolument les performances de mon serveur VSCode TS. C'est absolument inutilisable :D La rétrogradation vers le script dactylographié 3.8.3 semble restaurer au moins une partie des performances, mais cela pourrait en effet nécessiter plus d'attention.

@RyanCavanaugh rouvrir?

Je peux confirmer, je rencontre le même problème.

Pareil ici, ça vaut le coup de rouvrir !

Je confirme que mon VSCode a commencé à s'étouffer.

J'ai fini par supprimer les composants stylisés, cela ne nous a de toute façon pas apporté beaucoup d'avantages sur le natif de réaction. Les anciens objets JS simples avec opérateur de propagation et styles en ligne fonctionnent très bien sans problèmes de performances TS, IMO finit par être plus facile à lire le code qu'avec des composants stylisés de toute façon au moins sur RN.

Je vis l'enfer dans le havre CSS-in-JS lorsque je code avec VSCode.

@AndrewMorsillo @hilezir Je suis passé des composants stylisés à styletron, en utilisant TS 4. Les performances dans styletron sont bien meilleures à la fois dans vscode et dans le navigateur. Mais je ne connais pas styletron sur React Native.

@AndrewMorsillo @hilezir Je suis passé des composants stylisés à styletron, en utilisant TS 4. Les performances dans styletron sont bien meilleures à la fois dans vscode et dans le navigateur. Mais je ne connais pas styletron sur React Native.

Il est trop tard pour que nous procédions à ce changement, mais je n'ai pas entendu parler de styletron et j'aime définitivement plus son apparence que ses composants stylisés.

Y aura-t-il un nouveau problème ou ce problème sera-t-il rouvert? Il y a toujours de gros problèmes de performances avec @types/styled-components 5.1.2 et TS 3.9.7

J'ai passé une journée entière à essayer de comprendre comment accélérer VSCode et j'ai finalement compris que c'était @types/styled-components . Une fois installé, il suffit de taper n'importe quoi dans l'éditeur pour que tsserver.js (comme indiqué via VSCode Process Explorer) augmente > 100 % du processeur et augmente sans limite en mémoire. Le simple fait de supprimer @types/styled-components résolu ce problème.

J'utilisais TypeScript 4.0.3 et @types/styled-components 5.1.3.

quelqu'un peut-il suggérer une meilleure alternative aux composants stylisés. mon vscode se bloque complètement.

quelqu'un peut-il suggérer une meilleure alternative aux composants stylisés. mon vscode se bloque complètement.

essaye ça?

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

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

Il y a en fait une Pull Request ouverte pour améliorer les performances des types styled-components ' : https://github.com/DefinitelyTyped/DefinitelyTyped/pull/46510.