popcodeorg / popcodeorg/popcode

Add a type checker to Popcode's JS validations

Offen
#851 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

enhancement
Vorherrschende Sprache
JavaScript
Sterne
191
Forks
143
Ø Merge
4 T. 11 Std.
Gemergte PRs (30 T.)
5

Beschreibung

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

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Es werden keine Dateien oder Tests genannt. Beginne mit der Überprüfung der bestehenden JSHint- und Esprima-Validierungen und vergleiche anschließend browserkompatibles TypeScript und Flow mit den genannten Einschränkungen und Anforderungen an die Nachrichtenfilterung. Als abgeschlossen gilt die Auswahl eines Ansatzes, der unterstütztes JavaScript und unterstützte Bibliotheken prüft und nur korrigierbares, pädagogisch sinnvolles, barrierefreies und nicht dupliziertes Feedback anzeigt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
javascript, typescript
Bereich
frontend, web-dev
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Veraltet
Klarheit
Muss geklärt werden
Anfängerfreundlichkeit
20/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.