popcodeorg / popcodeorg/popcode

Add a type checker to Popcode's JS validations

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

Nessuno ha ancora preso questa issue.

enhancement
Lingua principale
JavaScript
Stelle
191
Fork
143
Merge medio
4g 11h
PR unite (30g)
5

Descrizione

Wouldn't it be cool if we could give students feedback based on type checking?
The likely constraints to any type checker we use:

  1. Runnable in browser
  2. Can parse regular JS
  3. Has typings for a healthy subset of Popcode's supported libs (jQuery, lodash, Bootstrap, Mustache)

The current most popular type-checked ~supersets of javascript are TypeScript and Flow.

Here's my opinion on how each breaks down against those 3 constraints (disclosure: I am much more familiar with Flow):

TypeScript:

  1. This blog post details how you can get TypeScript type checking in the browser. Adapting to Webpack is left as an exercise for the reader.
  2. I don't know enough to say. I know that TypeScript will be fine with trivial examples of untyped JS, but I don't know how well it does with more complicated code samples.
  3. TypeScript has typings for all four supported libs.

Flow:

  1. Flow has a (mostly undocumented) compiled-to-js version, which is used in the "Try Flow" sandbox. Instructions for building this file are at the bottom of these instructions.
  2. Flow is designed for the gradual introduction of types, and being run on code with no typings is a first class use case. That said, there are still a number of ways that the checker can get "confused", which is to say that Flow has opinions which will clash with a lot of beginner-level code patterns, in particular with regards to object mutability. Example.
  3. Flow has available typings for jQuery and lodash.

With both options, a major component of this feature will be filtering messages to ensure that anything students see will be

  • Fixable (e.g. not requiring type annotations or special syntax)
  • Pedagogically sound (we're not trying to teach them more advanced concepts like variance here)
  • Accessible (e.g. the Flow message in the example could be simplified to "Your object doesn't have the field 'newField'").
  • Unique (we already have JSHint and Esprima to complain about syntax issues and undeclared variables)

Other considerations:

  • bundle size
  • speed of checks

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.

Direzione di ricerca

Non sono indicati file o test. Inizia esaminando le validazioni esistenti di JSHint ed Esprima, quindi confronta TypeScript e Flow compatibili con i browser con i vincoli dichiarati e le esigenze di filtraggio dei messaggi. Il lavoro è completato quando viene selezionato un approccio che controlli JavaScript e librerie supportati, mostrando solo feedback correggibile, pedagogicamente valido, accessibile e non duplicato.

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

Valutazione

Stack tecnologico
javascript, typescript
Ambito
frontend, web-dev
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Ferma
Chiarezza
Da chiarire
Idoneità per principianti
20/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.