mints: 5.7kb の TypeScript コンパイラを作った
世の中の TypeScript コンパイラが大きすぎるので作りました。 ここで試せます。 jsx と jsx pragma のサポートもしたので、 preact も動いています。 実装方針 ビルドサイズ第一 とにかく軽量に mints自体が他のコードをビルドするときの速度ではない点に注意 現状、まともなエラーレポートが出ない。エラーメッセージをインライン化するとビルドサイズが増えるため。 空白行と型情報を落とすだけ ES5 への変換や commonjs への変換は実装しない enum と constructor と jsx のみ transform する特殊対応をしている 真面目な構文解析をしてない 例えば 1+1*2 のような binary expression は結合順を解析してない。型を落とすだけなら不要 prettier でフォーマットされたコードはコンパイルできるのが目標(空白行
「す゚み゚ま゚せ゚ん゚打ち゚込む゚全て゚の゚文字に゚コ゚ミ゚み゚た゚い゚な゚の゚つ゚い゚て゚る゚ん゚て゚す゚け゚と゚誰か゚原因を゚知り゚ま゚せ゚ん゚か゚？」スマホの謎のバグをツイッターの集合知が解決
厭世 ◇ 厭 @enseiitou す゚み゚ま゚せ゚ん゚打ち゚込む゚全て゚の゚文字に゚コ゚ミ゚み゚た゚い゚な゚の゚つ゚い゚て゚る゚ん゚て゚す゚け゚と゚誰か゚原因を゚知り゚ま゚せ゚ん゚か゚？
西暦5万年問題 - hitode909の日記
UNIX 元期からの経過ミリ秒を秒として扱ってしまうと、時刻が1000倍になって、最近の日時だと、西暦5万年くらいになってしまうことがある。 今日、Sentryを見てたら、Invalid date format: 53793-11-30みたいなエラーが流れてきて、これはミスって1000倍しているに違いない！とテンションが上がっていた。 野生の西暦5万年を発見して興奮している秒とミリ秒が別の型になってればこういう間違いを減らせそうだけど、システム内に閉じた部分では好んでepochを使いたい人はいないだろうし、epochをやりとりするところは、だいたい、システム同士の連携部分だったり、外部サービスからリクエストを受け取るときだったりで、そういうインターフェイスの入出力時に、桁が1000倍なってるかどうか、というのを機械的に判定するのは難しそう。 Dateが1970年を指し示していたら嫌な予感が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
