Are ESLint rules around performance worth advocating?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 20/100
- Tipo de issue
- Documentación
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- eslint, typescript
- Área
- documentation, performance
Línea de trabajo
Lee la página wiki de TypeScript enlazada sobre rendimiento y las reglas de ESLint mencionadas que recomiendan preferir interfaces y tipos de retorno explícitos. El issue solicita orientación de los maintainers sobre si se deben recomendar estas reglas y cuánto afectan al rendimiento; no identifica ningún archivo, prueba ni cambio concreto en la documentación que deba realizarse.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hey @DanielRosenwasser,
I do hope you're well. First up, this is not directly an issue with the wiki at all, but I thought this was a good place to have a conversation about your wiki page on performance.
I was just talking with @dragomirtitian about me writing a blog post which would show how to take a few of the tips in here and apply them with ESLint; there’s ESLint rules out there that can help with this. Essentially the main ones of interest are:
- Prefer Interface over Type https://github.com/cartant/eslint-plugin-etc/blob/main/docs/rules/prefer-interface.md
- Enforce return types https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/explicit-function-return-type.md
Titian posed the (entirely helpful) question:
I'm sure these make difference.. By at what point.. 1K loc? 10Kloc? 100? If this is a concern for huge scale projects is it really worth it for smaller projects? I mean shaving off 0.2s in a build doesn't seem worth it if I have to maintain a type and an inferable return type.
This is a great question. And I have to state a personal stylistic preference fortypes over interfaces, as well as preferring return type inference. Much less noisy. But perf is royalty and style is secondary.
My own feeling is that if you want to go with these rules, it’s easier if you start with them at the beginning of a project that you expect to grow. As retro-fixing all of these in a codebase would not be fun!
Anyway, rambling done. I have two questions for you if have a moment:
-
Is it worth blogging to advocate that people use the above ESLint rules? Or is this potentially transient advice? Something that’s useful now but could change as the compiler evolves?
-
Do you have a feeling for what level of difference that following these standards can make? The answer will no doubt be "it depends", but I'm curious if you happen to have an idea for what the boundaries of success could look like here. So, is it possible to say something like "enforcing return types on functions has been observed to improve type checking performance by up to 40%", or "preferring
interfaces overtypes has been observed to improve type checking performance by up to 20%"? Actually having an idea of the level of difference that could be made is a super helpful piece of info. (Essentially this is Titian's question 😄 )
I hope you don't mind me posting the question here. I did consider DMing you instead, but I thought I'd do a @swyx and "learn in public" 😄
- Lenguaje dominante
- JavaScript
- Estrellas
- 759
- Forks
- 315
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/TypeScript-wiki
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 50/100
microsoft/TypeScript-wiki#327 ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 15/100
microsoft/TypeScript-wiki#323 ·
-
Diagnostic Message Codes Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 25/100
microsoft/TypeScript-wiki#307 · 1 reacción ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 35/100
microsoft/TypeScript-wiki#293 · 2 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
microsoft/TypeScript-wiki#260 · 2 comentarios ·
Todos los issues de microsoft/TypeScript-wiki
Issues similares
-
bug confirmed issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
open-webui/open-webui#30750 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Mend: dependency security vulnerability untriaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100