popcodeorg / popcodeorg/popcode

Add a type checker to Popcode's JS validations

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

Nadie ha tomado este issue todavía.

enhancement
Lenguaje dominante
JavaScript
Estrellas
191
Forks
143
Merge medio
4 d 11 h
PR fusionados (30 d)
5

Descripción

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

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.

Línea de trabajo

No se nombran archivos ni pruebas. Empieza revisando las validaciones existentes de JSHint y Esprima; después, compara TypeScript y Flow compatibles con el navegador con las restricciones indicadas y las necesidades de filtrado de mensajes. Se considera terminado cuando se haya seleccionado un enfoque que compruebe el JavaScript y las bibliotecas compatibles, y muestre únicamente comentarios corregibles, pedagógicamente sólidos, accesibles y no duplicados.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
javascript, typescript
Área
frontend, web-dev
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
20/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.