Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Are ESLint rules around performance worth advocating?

Aperta
#266 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
eslint, typescript

Direzione di ricerca

Leggi la pagina wiki di TypeScript collegata sulle prestazioni e le regole ESLint citate che raccomandano di preferire le interfacce e i tipi di ritorno espliciti. L’issue chiede indicazioni ai maintainer sull’opportunità di promuovere queste regole e su quanto incidano sulle prestazioni; non identifica alcun file, test o modifica concreta alla documentazione da apportare.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
JavaScript
Stelle
759
Fork
315
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/TypeScript-wiki

Tutte le issue di microsoft/TypeScript-wiki

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.