mod.ts
Deno推奨のモジュールのエントリーファイルの名前 module_name/mod.tsという形式
モジュールのexportをまとめておいたりする
hr.icon
2019/5/10
なんか有耶無耶になってどうでもよくなったっぽいkeroxp.icon
2019/1/20
また議論が再燃しているkeroxp.icon
Ry曰く、
「mod.tsさすがに使いすぎじゃね?」
「exportたらい回しするの意味なくね?」
keroxp.iconせやな
2019/1/11
keroxp.iconは意見を取り下げました
これによりdeno_stdの再編成が近いうちに行われるかと
コアチームの誰からも共感を得られなかったし、3rd partyももう従い始めていたので
どうなるのかはわからないけど、しばらくは様子見することに
keroxp.icon2019/1/7
色々コアコミッタの方と議論したが覆りそうにない…
彼らの主張は「mod.tsがあったほうがimportしやすい」に集約されていて反論しづらい
その割にはmod.tsの配置スタイルに一貫性がなさそうにみえる
そもそもkeroxp.iconはindex.tsormod.tsにexportを集約する事自体に難色を示しているのでまとまるはずはないのであった
npmやらrubyなら明確に「パッケージ」という概念があるから集約するのは自然
でもdenoには明確にひとまとまりの「パッケージ」という概念はない
あるのはファイルとそのURLだけ
2019/1/5現在、これがモジュール化(サブディレクトリ化)されたモジュールのエントリーファイル名になろうとしている
keroxp.iconはこれについて反対している
deno_stdがmod.tsを公式で採用してしまえば、事実上の標準になってしまう
denoはURLからならどこからでも読み込めるのだからこういう中途半端なルールは採用すべきでないと思う
mod.tsが存在するからと言って使う側はほとんど得をしない
結局URLで書くことになるし、その作業はエディタがやってくれるので
mod.tsがあっても中身にexportされてるものはバージョンによって異なるはずなので別の問題が出てくる
むしろむしろあったりなかったりしたりして混乱するし、タダの慣習なのにないと「なんで無いんだ」と怒る人が出てくる恐れがある
Goはこういう仕組みなくしてシンプルに解決しているのだから変なルールを作るべきではないと思う
testingモジュールのエントリーはtesting.tsでもindex.tsでもいい
node.jsも基本はindex.jsがエントリーたけどpackage.jsonで変えられるから結局誰も守ってない
仮にtestingがモジュールの名前なら、
testing.ts
(testing_test.ts)
testing/
assert.ts
assert_test.ts
のようなのような構成にするほうが自然だと思う
2019/1/5現在、x/testingは
testing/
mod.ts
test.ts
のように変な構成になってしまっている
mod.tsをpublic apiの置き場所にしたところでpackage-privateのものもURLで読み込めてしまう
それはTSの仕様なのだから仕方ない
Goは関数名や変数名の大文字小文字でACLを実現しているが、TSにはそういう仕組がないので
hr.icon