# TODO - `周辺ツール面` - generator、他の人もシステムに組み込むならテスト用途等に使えるかもしれないので一応別リポジトリに切り出してnpmにリリースしておく…？ - prettier的なやつを作ってもいいかもしれない。ジェネレータみたいなのはほぼあるのでそれっぽくなりそう。 - `仕様面` - CHB-2のエラーメッセージ、合ってる？ - [ ] denominatorもパースしたい。なぜなら「7/1」のようにディグリーの時の「/1」とかを出したいので。 - 最悪アプリケーション側でdenominatorの最初の1,2文字をパースしてしまえば一応OKでもある。（denominator自体がコードでなければ。アプリケーション側でそこがコードが来ないように実装されているならば） - というかdenominatorをパースしなかったのはそこがベース音だけの場合とコード書いちゃう場合とで区別がつかなくてめんどいなとなったからだった。 - うーん - ドキュメントやzennを修正 - accidental、nullになってしまう？型的にはオプショナルな型が生成されるのに。 - どうしても直せないならパッチ当てるくらいはした方がいいのかも（またはPR送る） - なぜかspec.tsの中でimportできないのがある。なぜだろう、？これは修正する必要がある - エラーメッセージの内容を精査して意味的に正しくする - エラーメッセージ、現状は1個しか返せないが、パーサーなら複数返してほしいな。そういう懸念とか集めてからV1の公開にしたいな - これやる方法、エラー出たmatchはエラーをスタックに詰んだ時点でbreakして、一旦なかったことにして次のループに進めば良い気がする - エラー時、できればスタックトレースがほしい。 - line!, file!, column!とか使えばソース上の位置情報が取れるっぽい。というかスタックトレース取れないものか？ - エラー情報、GPTに聞いてみたら以下もありらしい ```txt message　・・・エラーの具体的な説明。 errorType　・・・エラーの種類やコード（例：「SyntaxError」、「TypeError」など）。 context　・・・エラーが発生したコードの周辺部分。特定のエラーをより明確に理解するのに役立ちます。 severity　・・・エラーの重大度。例えば、「警告」、「エラー」、「致命的エラー」など。 suggestions　・・・エラーの解決策やヒント。 ``` - `-5`と`b5`を同じものと扱うのはstrumの技術的に一旦諦めたので、後で対応する。今は一旦`b5`のみ対応 - strumやめて独自で管理すれば一応は対応可能なはず - 例えば単に以下のようなオブジェクトの配列にするとかね { name: "FlatFive", aliases: ["-5", "b5"], intervals: [-5], } - エスケープとか対応するならする - というかエラーのみならず正常パースしたTokenにもPosition周りの情報を付けたほうが逆パース（？）をしやすいのでは。その場合ASTを大改修になるのでやめておくか… - いやもしかしたらだけど、ASTツリー自体にフィールドを追加するのでなく単にtokenizerの結果も返すだけでいいのかも。以下イメージ ```json { "ast": AST, "tokensWithPosition": [ { "token": Token, "position": Position } ] } ``` - set_panic_hook、イメージ通りに使えてないのでは？これを使えばcatchに行かないようにできるかも？ - 本当はpanic時にスタックトレースを出したいので、出せるようにしてほしいなと思う - というかpanicを出さないようにしてほしい。これはjs側でもtry-catchの必要性が出てきてしまうので。 - これ？ - ハッキーなのか…？となるとwasm-packを使ってるならば避けたほうが良かったりするのかな…一旦置いておこう… - `ジェネレータ` - 別リポジトリに移動し、githubリリースする。内部利用でしかないのでnpmに公開するまでは不要 - `保守面` - rrというデバッガがよいらしい - tokenizerのexpectedをfixtureファイルに変数として置いておいて、それをparserのinputに使いまわしたい。でないとそもそもparserの中間状態としてのinputが正しいのかの時点で知識が要求されてしまって面倒 - いや逆に変かな？ - 新バージョンをリリースしたら勝手にREADME内に書かれてるバージョンも上げたい。github actions使ってsedでいじってREADMEをコミットしちゃっていい気がする - `パフォーマンス面` - パフォーマンスのテストもしたい。 - 例えば10回ループさせて平均実行完了時間を出しておいて、ファイルに記載しておく。コミットを戻せばその時のパフォーマンスがわかるように鳴る感じ。 - これ、コミットごとに数値化しておいてグラフで比較できるようにしたい。全コミットのその値を出すのは面倒かもなのでファイルに書き出していく？うーんどうしたらいいかから考えて - `コードクオリティ面（むしろチマチマやる方がメンテ感が出るのもあるので、あとの方がよいまである）` - conventional commitにすれば、githubのリリースの自動生成がいい感じになるんだな…？となると従っておきたいところ（あとで） - e2eテスト、ちゃんと一度パッケージングしたものでやったほうがよいはず。でないと「importできるのにundefined」問題はありうる。 - importできるファイルがスネークケースになっている件、単純にキャメルケースにできるならする - `C[key=A]`はバリデーションで落とす - カバレッジ見て足りてないところをリファクタしていく - パフォーマンスチューニング（cloneを減らすとか） - 全体的にリファクタ等 - chord_detailed.rs、extension周りのコードが汚いので修正したい - serde詳しくなる - exhaustive matchできてないところがあるかもなので網羅 - そもそも全て作り直すとか - メタ情報が重複した時のエラーが不足しているので追加？ - まだstrum使ってない箇所あるので使う（Accidentalとか） - 逆にserdeを使えばstrum使わなくてもいい可能性感じるので見てみる - is_token_char、Token::VARIANTSを使って書き換える - コメント追加 - 関数に切り出し - prettifyされない。動かなくなってるかも - lefthookの`commit-msg`フックでコミットメッセージに日本語入ってたら落としたい。なぜかうまくいかず一旦諦めた。`commitlint`とか使えばいいのかも - wasm-bindgen-testの盛り込み - 不要ならば無しでいいけども調べてほしい - なんかe2eでやってるから不要っぽい? - こういうのドキュメントに残しておきたいな