Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Are ESLint rules around performance worth advocating?

Abierto
#266 0 comentarios 0 reacciones 0 asignados Ver en GitHub

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

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:

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:

  1. 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?

  2. 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 over types 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

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/TypeScript-wiki

Todos los issues de microsoft/TypeScript-wiki

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.