Definitelytyped: [@types/styled-components] Leistungsprobleme beim Compiler

Erstellt am 2. Apr. 2019  ·  37Kommentare  ·  Quelle: DefinitelyTyped/DefinitelyTyped

Das Hinzufügen der neuesten Version von @types/styled-components zu einem bestehenden Projekt führt zu einer Verlängerung der Build-Zeiten um etwa 1-2 Minuten, wenn die neueste [email protected] verwendet wird.

Mit diesem Seed-Repository habe ich die folgenden Versionen getestet:

w/o     2.3s
4.0.0   5.6s
4.1.0   8.0s
4.1.5   8.0s
4.1.10  10.1s
4.1.11  90.1s
4.1.12  97.1s

Mein Computer ist ein Linux 4.18.0 (Ubuntu 18.10) Laptop mit einer i7-6700HQ CPU @ 2.60GHz

Es scheint klar, dass die Version 4.1.11 dieses Leistungsproblem verursacht. Der PR für diese Version ist #33061. Warum, weiß ich wirklich nicht - ich habe versucht, in die Interna des Compilers einzudringen, um zu sehen, wo er hängen blieb, aber ich konnte es nicht verstehen.

  • [x] Ich habe versucht, das Paket @types/xxxx und hatte Probleme.
  • [x] Ich habe versucht, die neueste stabile Version von tsc zu verwenden. https://www.npmjs.com/package/typescript
  • [x] Ich habe eine Frage, die für StackOverflow unangemessen ist. (Bitte stellen Sie dort entsprechende Fragen).
  • [x] [Erwähnen](https://github.com/blog/821-mention-somebody-they-re-notified) die Autoren (siehe Definitions by: in index.d.ts ), damit sie es können Antworten.

    • Autoren: @eps1lon @Igorbek @Jessidhia

Hilfreichster Kommentar

@RyanCavanaugh wiedereröffnet?

Alle 37 Kommentare

Passiert das auch mit Typoskript 3.3?

Ich hatte das gleiche Problem

Paket.json

devAbhängigkeit

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

Abhängigkeit

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

Mein Problem ist, dass es so aussieht, als ob Webpack & webpack-dev-server @types/styled-components nicht analysieren können. Denn bei Verwendung nur gestylter Komponenten gab es kein Problem. Es passiert immer, wenn @types/ styled-components @

Bevor ich das Problem von @voliva sah , fand ich ein Endlosschleifenproblem von Webpack, da es die CPU-Ressource zu 100% verwendet.

Nachdem die @types/styled-compoents-Version auf 4.1.5 geändert wurde, sieht es so aus, als ob alles in Ordnung ist.

@eps1lon : Nein, Typoskript 3.3 ist in Ordnung; Insbesondere sieht es so aus, als ob das Problem unter der Version

Ich glaube, ich habe das Problem mit dem Seed- Repository von @voliva auf die rekursive Verwendung von OmitU , die in @types/styled-components Release 4.1.1 hinzugefügt wurde, identifiziert. Hier ist seine Definition :

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

Und hier sind die beiden Orte, an denen OmitU in index.d.ts :

Definition von WithOptionalTheme

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

Verwendung von WithOptionalTheme (in der Definition von StyledComponentProps )

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

Etwas an der von der Union verteilten OmitU Zuordnung über andere OmitU scheint den Compiler zum Stolpern zu bringen. Wenn eine oder beide dieser Instanzen durch ein normales Omit , das sich nicht auf Unions verteilt, wird die Kompilierungszeit unter Typskript 3.4.1 auf ungefähr 10 Sekunden reduziert.

(Beachten Sie, dass der Typ ReactDefaultizedProps auch auf PickU verweist, was die besonders langen Laufzeiten in der zweiten Zeile der folgenden Tabelle erklären mag.)

Um dies zu testen, habe ich einen oder beide der verteilten OmitU s mit einem der folgenden ausgetauscht:

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

Hier ist time yarn tsc ausgeführt gegen Typoskript 3.4.1 , 3.4.0-dev.2019 0226 und die unmittelbar vorherige Version 3.4.0-dev.2019 0223 :

| WithOptionalTheme Definition | WithOptionalTheme Nutzung | Typoskript 3.4.1 | Typoskript 3.4.0-dev.20190226 | Typoskript 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 | ...usw |
| OmitPickU | Omit | 0m9.654s | 0m6,796s | |
| Omit | OmitPickU | 0m8.990s | 0m6.485s | |
| Omit | Omit | 0m9.730s | 0m6.815s | |

Die Laufzeiten für Typescript 3.3.3 und 3.3.4000 stimmen mit 3.4.0-dev.20190223 überein – ungefähr 6 Sekunden auf der ganzen Linie.

Ich bin mit gestylten Komponenten nicht vertraut genug, um eine Lösung vorzuschlagen, aber ich hoffe, diese Daten helfen!

Ich kann bestätigen, dass ich das gleiche Problem habe. Auch das Downgrade von @types/styled-components auf 4.1.5 hat bei mir funktioniert. Ich bin auf Typoskript 3.4.1

@michsa Ich habe eine Reduzierung erwartet, aber keine 10x. Da dies in Typoskript 3.4 eingeführt wurde, könnten Sie auch ein Problem im Typoskript-Repository öffnen? Ich möchte sicherstellen, dass wir eine Fehlerbehebung nicht rückgängig machen, wenn es sich um eine Regression handelt, die in Typoskript behoben werden sollte.

Entschuldigung, dass ich anfangs nicht im Github von Typescript gesucht habe, ich habe dieses Problem gefunden, das derzeit untersucht wird: https://github.com/Microsoft/TypeScript/issues/30663

@weswigham @RyanCavanaugh Können wir bitte schnell eine Rückkehr zu den gestylten Komponententypen veröffentlichen, die nicht die Perf-Probleme von 3.4 haben.

Mit der Version VS Code 1.33 werden viele js-Benutzer die fehlerhaften Typen durch die automatische Typübernahme herunterladen. Wenn dies passiert, müssen Sie meiner Meinung nach entweder den Cache für die automatische Typerfassung leeren oder das feste @types/styled-components installieren, um den schlechten Zustand zu verlassen. Beides sind keine guten Erfahrungen für js-Benutzer. Je länger die schlecht ausgeführten Eingaben sind, desto mehr Benutzer werden betroffen sein (was eine schlechte Erfahrung für sie ist und auch für uns viel zusätzliche Arbeit bedeutet).

Dies scheint immer noch ein Problem mit @types/styled-components 4.1.19 und TS 3.6.3 zu sein. TS-Abschluss und Fehlerhervorhebung dauert 5-10+ Sekunden auf 2018 i7 MacBook Pro 15. Es müssen noch weitere Untersuchungen durchgeführt werden.

Ähm, das OP spricht von Zusammenstellungen aus den 90er Jahren (ein 9-facher Zeitsprung gegenüber der vorherigen Version der gestylten Komponenten), da beide neueren Versionen von TS Abschwächungen haben und spätere Versionen der gestylten Komponenten vereinfacht wurden, um nicht so viel Perf zu haben Probleme, 5-10s ist vielleicht nur Ihr Projekt und deps verhält sich normal.

Ich hoffe nicht! Es ist jetzt frustrierend langsam, wenn es in der Vergangenheit nicht war. Ich werde es weiter untersuchen und hier berichten, wenn es mit diesem Problem zusammenhängt.

Mein VSCde ist unbrauchbar (ts Fehler erscheinen und verschwinden nach wenigen Sekunden anstatt sofort), sobald ich @types/styled-components hinzufüge.

Ich verwende TS 3.6.4 und tippe 4.1.20.

@sregg macht diese PR verantwortlich, die die Schadensbegrenzung in @types/styled-components rückgängig gemacht hat: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323

(Und rollen Sie zurück zu v 4.1.19 , um das Problem lokal zu beheben)

@sregg macht diese PR verantwortlich, die die Schadensbegrenzung in @types/styled-components rückgängig gemacht hat: #39323

@typescript-bot sammelt Leistungskennzahlen, um „zu messen, ob [PRs] die Kompilierungszeiten oder die Reaktionsfähigkeit des Editors negativ beeinflussen könnten“. In PR 39323 schloss @typescript-bot: „Es sieht so aus, als hätte sich nichts zu sehr geändert.“ .

@sregg , können Sie sich einen Grund

(Seitenleiste: „Geh dieser PR die Schuld“ ist kein konstruktiver Vorschlag, @weswigham. Seien Sie bitte konstruktiv.)

Hier ist ein zusätzlicher Kontext:

@sregg hat eine schlechte Leistung bei der Verwendung von TypeScript 3.6.4 gemeldet: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/34391#issuecomment -548701239

Aber aus @weswighams Antwort in https://github.com/microsoft/TypeScript/issues/30663#issuecomment -507406245 habe ich verstanden, dass TypeScript-Versionen ≥3.5 nicht mehr die Leistungseinbußen mit sich bringen würden, die https://github.com/DefinitelyTyped /DefinitelyTyped/pull/34499 wurde zusammengeführt, um dies zu vermeiden.

Mit diesem Verständnis habe ich mich (mehr oder weniger) dafür entschieden, https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34499 über https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323 zurückzusetzen.

Die Leistungsmetriken des Bots basieren auf den Tests und leider sind die Tests der gestylten Komponenten sowohl in Bezug auf Größe als auch (komplexe) Nutzung ziemlich weit von einer echten App entfernt. Es tut sein Bestes mit dem, was es hat, aber es findet nicht immer _jedes_ Perf-Problem.

(Seitenleiste: "Schuld" im Sinne von "Git" - bitte nicht übel nehmen~)

Das macht Sinn, danke @weswigham!

Bis wir diesen Leistungsrückgang in Tests feststellen können, denke ich, dass die beste Vorgehensweise darin besteht, PR https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323 rückgängig zu machen , also habe ich PR https://github.com geöffnet

Nächste Woche werde ich daran arbeiten, einen Test basierend auf den freigegebenen Berichten (zB https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323#issuecomment-549015652) hinzuzufügen. Sobald das funktioniert, können wir (ex ante) andere Lösungen ähnlich wie https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323 evaluieren

@smockle haben Sie versucht, die neueste Version (4.4.2)


UPD: Gleiches mit sc Typings v5.0.1

@sregg
Mich auch!!!

Mein VSCode (*Eigentlich TS-SERVER) ist langsamer als zuvor. nach der Verwendung von gestylten Komponenten.
"@types/styled-components": "^5.1.0", "styled-components": "^5.1.1" "typescript": "^3.9.5"

Nach dem Downgrade von TS von 3.9.X auf 3.8.3 ging die Leistung für mich wieder normal. Verwenden von "@types/styled-components": "^5.1.0" und "styled-components": "^5.1.1" .

Danke @joaopaulobdac , ich habe an einem Projekt gearbeitet, das bei der Typoskript-Auswertung wesentlich langsamer ist als das andere, und es hat so lange erkannte , dass Styled Components der Übeltäter war. Ihre Lösung ist für mich erledigt. Scheint keine der 3.9x-Funktionen von Typoskript zu verwenden, daher war es ein ziemlich schmerzloser Wechsel!

Sollen wir dann eine neue Ausgabe erstellen? Kein Upgrade ist nur eine kurzfristige Lösung.

Ich habe das gleiche Problem mit dem neuesten Juni 2020 (Version 1.47) und "@types/styled-components": "^5.1.1"

Die Verwendung von Typescript 3.9.3 mit den styled-components Typen der Version 5.1.1 zerstört absolut meine VSCode TS Serverleistung. Es ist absolut unbrauchbar :D Ein Downgrade auf Typoskript 3.8.3 scheint zumindest einen Teil der Leistung wiederherzustellen, aber dies könnte in der Tat etwas mehr Aufmerksamkeit gebrauchen.

@RyanCavanaugh wiedereröffnet?

Kann ich bestätigen, habe das gleiche Problem.

Auch hier, eine Wiedereröffnung lohnt sich!

Ich bestätige, dass mein VSCode zu ersticken begonnen hat.

Am Ende habe ich gestylte Komponenten entfernt, es hat uns sowieso nicht viel von Reactive-Native gebracht. Einfache alte JS-Objekte mit Spread-Operator und Inline-Stilen funktionieren hervorragend ohne TS-Perf-Probleme, IMO ist am Ende leichter zu lesender Code als mit gestylten Komponenten, zumindest auf RN.

Ich erlebe die Hölle im CSS-in-JS-Port, wenn ich mit VSCode kodiere.

@AndrewMorsillo @hilezir Ich habe mit TS 4 von styled-components zu styletron gewechselt. Die Performance in styletron ist sowohl in vscode als auch im Browser viel besser. Aber ich weiß nichts über Styletron auf React Native.

@AndrewMorsillo @hilezir Ich habe mit TS 4 von styled-components zu styletron gewechselt. Die Performance in styletron ist sowohl in vscode als auch im Browser viel besser. Aber ich weiß nichts über Styletron auf React Native.

Es ist zu spät für uns, diese Änderung vorzunehmen, aber ich habe noch nie von styletron gehört und mag das Aussehen definitiv mehr als gestylte Komponenten.

Wird es eine neue Ausgabe geben oder wird diese Ausgabe neu aufgelegt? Es gibt immer noch große Leistungsprobleme mit @types/styled-components 5.1.2 und TS 3.9.7

Verbrachte einen ganzen Tag damit, herauszufinden, wie man VSCode beschleunigen kann, und fand _endlich_ heraus, dass es @types/styled-components . Wenn das installiert ist, würde das einfache Eingeben von etwas in den Editor dazu führen, dass tsserver.js (wie über VSCode Process Explorer gezeigt) zu mehr als 100 % CPU-Spitze führt und der Speicher unbegrenzt anwächst. Das einfache Entfernen von @types/styled-components behoben.

Ich habe TypeScript 4.0.3 und @types/styled-components 5.1.3 verwendet.

kann jemand eine bessere Alternative zu gestylten Komponenten vorschlagen. mein vscode friert komplett ein.

kann jemand eine bessere Alternative zu gestylten Komponenten vorschlagen. mein vscode friert komplett ein.

Versuche dies?

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

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

Es ist tatsächlich ein Pull Request geöffnet, um die Leistung von styled-components ' Typen zu verbessern: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/46510.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen