Definitelytyped: [@ types / styled-components] Problemas de rendimiento en el compilador

¿Ocurre esto también con el mecanografiado 3.3?

Experimenté el mismo 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"

dependencia

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

Mi problema es que parece que webpack & webpack-dev-server no pueden analizar @ types / styled-components. Porque cuando se usan solo componentes con estilo, no hay problema. Siempre sucede cuando se usa @ types / [email protected] al mismo tiempo.

Antes de ver el problema de @voliva , encontré un problema de bucle infinito en el paquete web porque usa el recurso de la CPU al 100%.

Después de cambiar la versión de @ types / styled-compoents a 4.1.5, parece que todo está bien.

@ eps1lon : No, mecanografiado 3.3 está bien; específicamente, parece que el problema comienza con la versión 3.4.0-dev.20190226 .

Usando el repositorio semilla de @voliva , creo que he identificado el problema con el uso recursivo de OmitU , agregado en la versión 4.1.1 de @ types / styled-components. Aquí está su definición :

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

Y aquí están los dos lugares en los que OmitU se usa en index.d.ts :

Definición de WithOptionalTheme

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

Uso de WithOptionalTheme (en la definición de StyledComponentProps )

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

Algo sobre el mapeo OmitU distribuido por la unión sobre otro OmitU parece estar haciendo funcionar el compilador. Si una o ambas de estas instancias se reemplaza con un Omit regular que no se distribuye entre las uniones, el tiempo de compilación se reduce a unos 10 segundos razonables aproximadamente en el texto mecanografiado 3.4.1.

(Tenga en cuenta que el tipo ReactDefaultizedProps también hace referencia a PickU , lo que puede ayudar a explicar los tiempos de ejecución especialmente largos en la segunda fila de la siguiente tabla).

Para probar esto, cambié uno o ambos OmitU s distribuidos por uno de los siguientes:

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

Aquí está time yarn tsc ejecutado contra mecanografiado 3.4.1 , 3.4.0-dev.2019 0226 , y la versión anterior inmediata, 3.4.0-dev.2019 0223 :

| Definición WithOptionalTheme | WithOptionalTheme uso | mecanografiado 3.4.1 | mecanografiado 3.4.0-dev.20190226 | mecanografiado 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 | |

Los tiempos de ejecución para mecanografiado 3.3.3 y 3.3.4000 son consistentes con 3.4.0-dev.20190223: aproximadamente 6 segundos en todos los ámbitos.

No estoy lo suficientemente familiarizado con los componentes con estilo para proponer una solución, ¡pero espero que estos datos ayuden!

Puedo confirmar que tengo el mismo problema. La degradación de @ types / styled-components a 4.1.5 también funcionó para mí. Estoy en mecanografiado 3.4.1

@michsa Esperaba una reducción, pero no 10x. Dado que esto se introdujo en mecanografiado 3.4, ¿podría abrir un problema en el repositorio de mecanografiado también? Me gustaría asegurarme de no revertir una corrección de errores si se trata de una regresión que debería corregirse en mecanografiado.

Lo siento, inicialmente no busqué en el github de mecanografiado, encontré este problema que están investigando actualmente: https://github.com/Microsoft/TypeScript/issues/30663

@weswigham @RyanCavanaugh ¿Podemos buscar publicar rápidamente una reversión a los tipos de componentes con estilo que no tienen los problemas de rendimiento en 3.4.

Con el lanzamiento de VS Code 1.33, muchos usuarios de js descargarán los tipos con errores a través de la adquisición automática de tipos. Una vez que esto sucede, para salir del mal estado, creo que debe borrar su caché de adquisición automática de tipos o instalar el @types/styled-components fijo. Tampoco lo son las buenas experiencias para los usuarios de js. Cuanto más largas sean las mecanografías de bajo rendimiento en la última versión publicada, más usuarios se verán afectados (lo cual es una mala experiencia para ellos y mucho trabajo extra para nosotros también)

Parece que todavía puede ser un problema con @ types / styled-components 4.1.19 y TS 3.6.3. La finalización de TS y el resaltado de errores tardan entre 5 y 10 segundos en 2018 i7 macbook pro 15. Necesito investigar un poco más.

Erm, el OP está hablando de compilaciones de los 90 (un salto de 9 veces en el tiempo de la versión de componentes con estilo anterior), ya que ambas versiones posteriores de TS tienen mitigaciones y la versión posterior de los componentes con estilo se simplificó para no tener tanto rendimiento. problemas, 5-10s es quizás solo su proyecto y los departamentos se comportan normalmente.

¡Espero que no! Es frustrantemente lento ahora cuando no lo era en el pasado. Voy a investigarlo más a fondo e informar aquí si parece estar relacionado con este problema.

Mi VSCde no se puede utilizar (los errores de ts aparecen y desaparecen después de unos segundos en lugar de instantáneamente) tan pronto como agrego @ types / styled-components.

Estoy usando TS 3.6.4 y tipos 4.1.20.

@sregg vaya a culpar a este PR que revirtió la mitigación en @types/styled-components : https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323

(Y retroceda a v 4.1.19 para solucionar el problema localmente)

@sregg vaya a culpar a este PR que revirtió la mitigación en @types/styled-components : # 39323

@ typecript-bot recopila métricas de rendimiento para "evaluar si los [RP] podrían afectar negativamente los tiempos de compilación o la capacidad de respuesta del editor". En PR 39323, @ typecript-bot concluyó: "Parece que nada ha cambiado demasiado". .

@sregg , ¿puedes pensar en una razón por la que las métricas existentes de @ typescript-bot no pudieran resaltar el problema de rendimiento del editor que observas?

(Recuadro: "culpe a este RP" no es una sugerencia constructiva, @weswigham. Sea constructivo).

Aquí hay un contexto adicional:

@sregg ha informado de un rendimiento deficiente al usar TypeScript 3.6.4: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/34391#issuecomment -548701239

Pero de la respuesta de @ weswigham en https://github.com/microsoft/TypeScript/issues/30663#issuecomment -507406245, entendí que las versiones de TypeScript ≥3.5 ya no incurrirían en la penalización de rendimiento que https://github.com/DefinitelyTyped / DefinitelyTyped / pull / 34499 se fusionó para evitar.

Entonces, con ese entendimiento, opté por (más o menos) revertir https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34499 , a través de https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323.

Las métricas de rendimiento del bot se basan en lo que hay en las pruebas y, desafortunadamente, las pruebas de componentes con estilo están bastante lejos de una aplicación real, tanto en tamaño como en uso (complejo). Está haciendo lo mejor que puede con lo que tiene, sin embargo, no siempre encuentra _todos_ problemas de rendimiento.

(Barra lateral: "culpar" en el sentido de "idiota"; por favor, no se ofenda ~)

Eso tiene sentido, ¡gracias @weswigham!

Hasta que podamos detectar esta regresión de rendimiento en las pruebas, creo que el mejor curso de acción es revertir PR https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323 , así que abrí PR https://github.com / DefinitelyTyped / DefinitelyTyped / pull / 40095 para hacerlo.

La semana que viene, trabajaré para agregar una prueba basada en los informes (por ejemplo, https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323#issuecomment-549015652) que se compartieron. Una vez que esté funcionando, podemos (ex ante) evaluar otras soluciones similares a https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323.

@smockle, ¿ ha intentado ejecutar la última versión (4.4.2)? Parece que el error de rendimiento ha vuelto, y rebajar a 4.1.19 ayuda.

UPD: Lo mismo con sc typings v5.0.1

@sregg
¡¡¡Yo también!!!

Mi VSCode (* En realidad TS-SERVER) es más lento que antes. después de usar componentes con estilo.
"@types/styled-components": "^5.1.0", "styled-components": "^5.1.1" "typescript": "^3.9.5"

Después de degradar TS de 3.9.X a 3.8.3, el rendimiento volvió a la normalidad para mí. Usando "@types/styled-components": "^5.1.0" y "styled-components": "^5.1.1" .

Gracias @joaopaulobdac , he estado trabajando en un proyecto que es sustancialmente más lento en la evaluación de mecanografiado que el otro, y me tomó tanto tiempo darme cuenta de que Styled Components era el culpable. Tu solución ya está hecha por mí. No parecía estar usando ninguna de las características 3.9x de mecanografiado, ¡así que fue un cambio bastante sencillo!

Entonces, ¿deberíamos crear un nuevo problema? No actualizar es solo una solución a corto plazo.

Estoy experimentando el mismo problema con la última versión de junio de 2020 (versión 1.47) y "@ types / styled-components": "^ 5.1.1"

El uso de mecanografiado 3.9.3 con la versión de tipos de componentes con estilo 5.1.1 destruye absolutamente el rendimiento de mi servidor VSCode TS. Es absolutamente inutilizable: D La degradación a mecanografiado 3.8.3 parece restaurar al menos parte del rendimiento, pero esto de hecho podría necesitar más atención.

@RyanCavanaugh reabrir?

Puede confirmar, experimentando el mismo problema.

Lo mismo aquí, ¡vale la pena reabrir!

Confirmo que mi VSCode ha comenzado a ahogarse.

Terminé eliminando los componentes con estilo, de todos modos no nos proporcionó un montón de beneficios en react-native. Los objetos JS simples y antiguos con operador de extensión y estilos en línea funcionan muy bien sin problemas de rendimiento de TS, IMO termina siendo más fácil de leer el código que con los componentes con estilo de todos modos, al menos en RN.

Estoy experimentando un infierno en el paraíso de CSS-in-JS cuando estoy codificando con VSCode.

@AndrewMorsillo @hilezir Cambié de componentes con estilo a styletron, usando TS 4. El rendimiento en styletron es mucho mejor tanto en vscode como en el navegador. Pero no sé sobre Styletron en React Native.

@AndrewMorsillo @hilezir Cambié de componentes con estilo a styletron, usando TS 4. El rendimiento en styletron es mucho mejor tanto en vscode como en el navegador. Pero no sé sobre Styletron en React Native.

Es demasiado tarde para que hagamos este cambio, pero no he oído hablar de Styletron y definitivamente me gusta su apariencia más que los componentes de estilo.

¿Habrá un nuevo problema o este problema se reabrirá? Todavía hay grandes problemas de rendimiento con @ types / styled-components 5.1.2 y TS 3.9.7

Pasé un día entero tratando de averiguar cómo acelerar VSCode y _finalmente_ descubrí que era @types/styled-components . Cuando está instalado, simplemente escribir cualquier cosa en el editor haría que tsserver.js (como se muestra a través de VSCode Process Explorer) aumente> 100% de CPU y crezca sin límites en la memoria. Simplemente quitando @types/styled-components solucionó esto.

Estaba usando TypeScript 4.0.3 y @types/styled-components 5.1.3.

¿Alguien puede sugerir una mejor alternativa a los componentes con estilo? mi vscode se congela por completo.

¿Alguien puede sugerir una mejor alternativa a los componentes con estilo? mi vscode se congela por completo.

¿prueba esto?

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

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

En realidad, hay una solicitud de extracción abierta para mejorar el rendimiento de los tipos styled-components ': https://github.com/DefinitelyTyped/DefinitelyTyped/pull/46510.