popcodeorg / popcodeorg/popcode

Add a type checker to Popcode's JS validations

Ouverte
#851 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

enhancement
Langage dominant
JavaScript
Étoiles
191
Forks
143
Merge moyen
4 j 11 h
PR mergées (30 j)
5

Description

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

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Aucun fichier ni test n’est indiqué. Commencez par examiner les validations existantes de JSHint et Esprima, puis comparez TypeScript et Flow compatibles avec les navigateurs aux contraintes énoncées et aux besoins de filtrage des messages. Le travail est terminé lorsqu’une approche est sélectionnée pour vérifier le JavaScript et les bibliothèques pris en charge, tout en n’affichant que des retours corrigeables, pédagogiquement pertinents, accessibles et non redondants.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
javascript, typescript
Domaine
frontend, web-dev
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
20/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.