popcodeorg / popcodeorg/popcode

Add a type checker to Popcode's JS validations

オープン
#851 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

enhancement
主要言語
JavaScript
スター
191
フォーク
143
平均マージ
4日 11時間
マージ済み PR(30日)
5

説明

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

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

ファイルやテストは指定されていません。まず既存のJSHintおよびEsprimaの検証を確認し、次にブラウザー互換のTypeScriptとFlowを、提示された制約およびメッセージフィルタリングの要件と比較します。対応しているJavaScriptとライブラリをチェックし、修正可能で、教育的に妥当で、アクセシブルかつ重複していないフィードバックだけを表示するアプローチを選定できれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
javascript, typescript
領域
frontend, web-dev
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
20/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。