mjsって何でしょう？ #94

satakagi · 2020-12-09T15:18:25Z

micro:bit , RPi用の*.jsのドライバ*1を開発している範囲ではmjsという拡張子のコードは使わないので、よくわかりません。コードを見てみると、ほとんど同じなので、どちらかから自動生成しているように見えるのですがよくわからないので説明を。

1から何か自動的にmjsが生成できるのならばあまり気にはなりませんが、逆にmjsを作らないとjsを登録できないとかになりますと、私の開発スタイル(.jsのコードを直接いじってmicrobitやRPiでトライアンドエラーする)からするとかな～り面倒です。

gurezo · 2020-12-09T15:30:33Z

@satakagi
気になって調べてみました。

https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide/Modules
https://blog.jxck.io/entries/2017-08-15/universal-mjs-ecosystem.html

自分もこれから理解してみます。

kou029w · 2020-12-10T01:13:35Z

@satakagi
@gurezo さんの書かれている通り、ESModules (つまりES標準によって定められているモジュールの import/export 構文) に対応したフォーマットです。
rollup.js によって *.mjs ファイルから *.js ファイルをビルドしています。
package.json の module プロパティに与えた *.mjs ファイル、より正確には rollup.config.js の input に指定しているファイルで、これを元にして UMD (Universal Module Definition) パターン (つまりブラウザーやNode.js両方で ES Modules 以外の手段でのモジュールのインポート) に対応した *.js ファイルが作られています。
これらは、このリポジトリに移行する際に ES Modules と UMD (Universal Module Definition) をサポートできるようにしたため、存在しています。

kou029w · 2020-12-10T01:44:05Z

ES Modules (.mjs) を使って開発する例:

ブラウザー上で従来 <script src=""> で書いていた部分は、次のように書き換えることで引き続き機能します。

<script type="module">
  import ADT7410 from "./adt7410.mjs";
</script>

あるいは

<script type="module" src="./main.js"></script>

main.js

import ADT7410 from "./adt7410.mjs";

もしGitHubにあるmasterブランチのファイルを参照するのであれば、

import ADT7410 from "https://cdn.jsdelivr.net/gh/chirimen-oh/chirimen-drivers@master/packages/adt7410/adt7410.mjs";

など。

kou029w · 2020-12-10T01:51:17Z

ES Modules そのものは、現代の多くのブラウザーでは利用可能ではあり、また、Node.jsに関してもv15以降は正式にサポートされるようなので、Universal JS を目指していくという観点では私個人としてはおすすめしておきたいところですがいかがでしょうか。

satakagi · 2020-12-10T02:18:16Z

チュートリアルやExamplesの<script>の記述なども奇麗にmjsや、ESModules？import?に直した状態にするのであれば良いのですが、そうでない今の状況ですと開発の手間がかかりそう（このままExamplesやチュートリアルが従来のままだと、人力でimportから<script>に書き換えたりなどいろいろやらないとならないですよね？　多分typoの嵐）
そして、その開発のやりかたが煩雑でない形で色々な開発環境で開発している人（ちなみに私はWindows+cygwin、エディタはサクラエディタですｗ）にも十分ケアされているかがポイントだと思います。

非同期の書き方をasync awaitを使うことを決めたときも、　古典的なjavasctiptに無いものなので、ドキュメントなどをいろいろケアしたうえで全面適用することにしましたので、今回もこれに変更したいのであればそういうケアが必要だと思います。

kou029w · 2020-12-10T02:20:38Z

開発の手間がかかりそう

https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples に提供している内容で問題ないかなと考えています。

kou029w · 2020-12-10T02:21:27Z

たしかにそうですね。。。 > 今回もこれに変更したいのであればそういうケアが必要だと思います。

kou029w · 2020-12-10T02:22:12Z

その点は UMD によってサポートしていくつもりで考えていました。

satakagi · 2020-12-10T02:25:01Z

https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
あ、これの存在を認識してませんでした。今後はExamplesもこれをマスターにするのですか？

よくわからないのですが、私の場合、これまではchirimen(-rip3)やchirimen-microbitのExampolesを自分の持っているホスティング(svg2.mbsrv.net)にコピーしたものでExamples(ドライバ含む)のトライアンドエラー開発を行っています。そのためコードの本家はjsです。

satakagi · 2020-12-10T02:27:05Z

特に今ISSUEに上がっていたような既存のドライバのバグや改善を考えると、マスターがどれなのかをきちんと決めておかないと　カオスになるので、
https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
がRPIもMICROBITも含め、今後はマスターになるということであれば、そういう合意形成をしてからだと思います。

kou029w · 2020-12-10T02:28:50Z

従来のJSで開発進めるということであれば、Node.jsにも対応しているUMDフォーマットでの開発をおすすめしたいです。

(function (global, factory) {
	typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory() :
	typeof define === 'function' && define.amd ? define(factory) :
	(global = typeof globalThis !== 'undefined' ? globalThis : global || self, global.ここにクラスの名前 = factory());
}(this, (function () { 'use strict';
// ここに本体
})));

私個人の考えとしては、ESMのサポートはおすすめですが、ブラウザーとNode.js両方をサポートしてくUniversalなJSモジュールが提供されているのであれば本リポジトリとしてはどっちでもよいかなと考えていました。

kou029w · 2020-12-10T02:30:03Z

一方で https://github.com/chirimen-oh/chirimen.org に関しては、たしかに今後の方針を合意とってどちらか決めていくほうがよいとも思いました。

satakagi · 2020-12-10T02:30:10Z

jsを本家にして、そこからmjsが生成できるなら、どっちでもいい開発スタイルになると思いますが、その辺はどうなのでしょう？　今はmjsからjsを生成してる感じですよね？

kou029w · 2020-12-10T02:30:46Z

jsを本家にして、そこからmjsが生成できるなら、どっちでもいい開発スタイルになると思いますが、その辺はどうなのでしょう？

調べたことないですね。。。

kou029w · 2020-12-10T02:30:59Z

今はmjsからjsを生成してる感じですよね？

はい

satakagi · 2020-12-10T02:31:29Z

であれば少なくとも私は厳しいなぁと思います。＞mjs, ESModule

satakagi · 2020-12-10T02:45:32Z

お、UMDというものもあるのですね。
この記法？作法？は、ドライバだけに適用すればいいのでしょうか？
それともサンプルプログラムのmain.jsみたいなものにも適用させておく必要がありますか？
もしサンプルにも適用が必要だとすると、このUMDの初心者向けの解説が必要だと思います。
そうでなくてもUMDの説明が欲しいですね・・
mjs, ESModule, UMD, yarn, rollup.js わからない単語や仕組みがたくさん。

kou029w · 2020-12-10T02:45:56Z

それともサンプルプログラムのmain.jsみたいなものにも適用させておく必要がありますか？

いいえ、必要ないです

kou029w · 2020-12-10T02:46:12Z

この記法？作法？は、ドライバだけに適用すればいいのでしょうか？

はい、そのとおりです。

satakagi · 2020-12-10T02:48:21Z

はい、私もNode,jsで使えるようになったことはすごく良いことだと思っています。（実用的になりましたよね！）
ただ、ちょっといろいろ新しいことが多いのと、環境も大分いろいろ新しいことを理解したり、やらないと整備出来ない感じなので、　わかりやすい説明がないと　混乱しています。

satakagi · 2020-12-10T02:57:55Z

あとテストをどうするかも課題かな。全部の環境でドライバのテストを行う必要があるのか？　＞これかなりハードル高い

https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
に全ての環境で動くExampleを置く？　実質的にこれがテスト？

kou029w · 2020-12-10T03:01:20Z

https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
に全ての環境で動くExampleを置く？　実質的にこれがテスト？

Raspberry Pi/CHIRIMENブラウザーのものを配置しています
Node.jsのものはnode-examples/以下に現在配置しています

see also https://chirimen.org/chirimen-drivers/CONTRIBUTING#%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E6%A7%8B%E9%80%A0

kou029w · 2020-12-10T03:04:07Z

全部の環境でドライバのテストを行う必要があるのか？

ESMであること、あるいはUMDであること、いずれかが保証されているのであればある環境のみで十分と考えます

satakagi · 2020-12-10T03:07:30Z

とすると、
ESMであること、あるいはUMDであること、いずれか
とすることの新たな合意形成（それに至るためのわかりやすい説明や開発方法のケア）が必要ですね。
あと、たぶんですがESMで書いた場合、いわゆるチュートリアルの現行の作法に適合しないので、rollup?でjsを作る必要がある？

satakagi · 2020-12-10T03:08:29Z

ちなみに、UMDって　あらゆるjsで例外なく　↑をコピペすれば成立するのでしょうか？

satakagi · 2020-12-10T03:18:36Z

今後は、Raspberry Pi用のExamplesは
https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
に置きさえすれば良いということでしょうかね？
それと、たしかRaspberry Pi用のExamplesはgc配下の公式なものとcontribのものとに分けていたと思う（私が書いたものは全部contrib下においてます）のですが、今後はこの区別は無くします？区別をなくす場合は、これまで区別していた理由（テストが個人的にだけ行われていて不十分だから）をどう解釈しましょうか？

あ、そうするとmicrobitのものも同じく
https://github.com/chirimen-oh/chirimen-drivers/
の方に置くのが適当ですね。
ただ、せっかく同じリポジトリにExamples（兼test）をまとめるなら、全く同じコードからそれぞれの環境用のものが自動的に生成できると上に書いた手間がなくなるけれど、それは難しいかな？

dynamis · 2020-12-10T03:57:57Z

browser/node 両対応をするという意味でも、 (async/await を教えるのと同じく)徐々に標準として広く使われるようになっていくモジュール (ES Module のほう) でコードを読み書きすることを教えるという意味でも、モジュールのコードと記法に徐々に移行していく必要はあると考えています。

しかし、今回ご迷惑をおかけしてしまったように、モジュールやその歴史的経緯などを理解・把握して後方互換用のコード (UMD) の生成手順までを全て理解するのは正直大変だと思います。

その大変さは分かっている人がケアして、普通に CHIRIMEN を使う人やドライバを書いてくれる貢献者にはなるべく苦労をかけないようにしないと不味いとは思います。移行作業自体が大変でそのケアまでが間に合ってないままで申し訳ないです。

大まかに言って困るポイントはこの辺りでしょうか

CHIRIMEN 利用者

今のところチュートリアルなどは基本旧来のブラウザ向けのものだけの想定で書いてもらって、モジュールについては意識しないで済むようにしています。

但し、そうするためにドライバ開発側は ESM でコードを書くだけでなく、UMD 形式に変換したものを用意する必要がある状態になっています。

モジュールの利用が浸透してくるときか何処かのタイミングで (async/await を導入したように) チュートリアル/example もモジュールに切り替えたい・切り替えるべきと考えています (がその場合でも後方互換・これまでの使い方の人のために UMD 形式の生成は必要)。

ドライバ開発者

node/browser 両対応にするには ES Module で実装・開発する必要があるため、どうしても次の 2 点の手間が増えてしまいます (通常の任意の js から ES Module を生成する手段は存在しないはず。一定のルールの中のものだけ変換できるならあり得るけどそれなら最初から ES module でかいた方が良い)。

ES module 形式なるように記述し、開発検証時は <script type=module> で読み込む
既存の形式で使う人のために UMD 形式に変換する処理を行ってからコミットする

この点についての丁寧な説明や負荷軽減のための対応や合意が無いままで進めてしまったのが問題でした。申し訳ありません。

前者については、@kou029w さんが最初に書いたように、<script type=module> にして import ...mjs するかするのと、ドライバ側ではグローバルでクラスを宣言していただけのものを最後に export default ADT7410; と付け足すだけで、今までと変わりなく開発して頂けるはずです。

後者については yarn build できる環境を用意するのが大変なケースもあるので、Github Actions などで自動生成・コミットできると良いかもです。議論頂いたように、ES Module として正しく動いてれば UMD として改めて動作確認は不要 (変換による非互換は無い) なので。

dynamis · 2020-12-10T04:27:16Z

UMDって　あらゆるjsで例外なく　↑をコピペすれば成立するのでしょうか？

(function (global, factory) {
	typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory() :
	typeof define === 'function' && define.amd ? define(factory) :
	(global = typeof globalThis !== 'undefined' ? globalThis : global || self, global.ここにクラスの名前 = factory());
}(this, (function () { 'use strict';
// ここに本体
})));

ですよね。なんか凄いハックコード書けば例外はあるかもですが、やってることは単純なので任意の JS が書けます。といっても冒頭のテンプレにクラス名を書かなきゃダメとか、本体という部分の最後で return してあげなきゃとか結局「UMD としてドライバを書くための手順」を覚える必要があるかと思います。

ES Module を browser/node がサポートするまでの間の過渡期に、何とかして単一 JS ファイルで両サポート強いようとして生まれた気持ち悪いテンプレと記法なので、リリースファイルとして UMD を提供するのは良いけど、開発・実装者が直接 UMD を書く・書き方を学ぶのはもうしないで、ES Module (mjs) を書いて import した方が簡単かつ今後の Web 開発一般で役立つ・見かけることが増える記法で良いかと思います。

そのためには既存の example は script タグと import 行の修正が必要で手間がかかるので、example/tutorial も ESM 化したいところで、そうしたものが

https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples

とも言えます (main.js で import する先のパスだけ変えれば開発版で試せる)。じゃぁ

今後は、Raspberry Pi用のExamplesは
https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
に置きさえすれば良いということでしょうかね？

については、そうしてしまいたいところだけど、そうするとチュートリアルの方も全面的に ESM/import の利用にしないとチュートリアル本文と example のコードの書き方が違って理解できないという問題が発生してしまいます。

私の認識では example の公式マスター？はまだ旧来の
https://github.com/chirimen-oh/chirimen/tree/master/gc
配下のもので、chrimen-drivers 配下の examples はドライバ開発者向け、ES Module をサクサクテスト・開発したい人向けのコードという状況です。

今のところ、メンテナだけが何とかすれば良いドライバは ESM がオリジナルという方式に切り替えたが、一般の CHIRIMEN 利用者 (ESM/import 知らない人も多い) の方までは切り替える判断はできていない (こちらはちゃんとコミュニティの相違で切り替えないとならないと意識して勝手にはしないでいる) 状態です。

example の方も ESM/import でオリジナル書いたら今の旧来の形式が自動生成されるようにできれば良いのですが、それもできておらず結局 examples が 2 つになってしまった状態です。

node 対応などと共にモジュール化の導入をしながらちゃんとコミュニティでの説明・フォローなどができていなかったところは、明日説明・議論させてください。

dynamis · 2020-12-10T04:42:14Z

私としては CHIRIMEN コミュニティは初学者向けのプログラミング環境であるので、利用者側であれ、ドライバ開発社側であれ、日常的にハックコードを書くことはせず、標準化されたコードだけを学んで開発ができるようにすべきと考えています。

そういう意味では ADM/CMD などは中身を読まずにドライバとして <script src=xxx.js> で読み込むときには出現しても良いけど、実際に自分で書くのは従来のブラウザのコードか、ES Module 形式として <script src=xxx.mjs> と import XXX のいずれかだけであると考えています。
(async/await に行く前に js deferred とかややこしい過渡期コードを挟まなかったのと同じ)

その意味で @kou029w さんの選定、セットアップには私も賛成しています。説明と合意が足りてなかった所は申し訳ありません。ミーティングでの説明やドキュメントの書き足しなどでフォローさせてください。

dynamis · 2020-12-10T05:19:15Z

ESM の案内・以降手順を書く話については単独 issue に分けました: #95

satakagi · 2020-12-10T06:15:59Z

方向性としては共感できるのですが、開発の手間を考えるとやはり抵抗感が強いですね。

理由はドライバ開発用のテストとExamples（こちらもこちらで別にテストも必要）の二つを作らないと仕事が完了しないところです。

トライアンドエラーなしにドライバが書けるなら大した手間ではないのかもしれませんが、そうはいきませんのでドライバを書くときには当然テスト用のwebAppsとセットで書いていきます。
これまでは何かの環境(RPiが多い)のExamplesをそのままテスト用のwebAppsとしして書いていたので手っ取り早かったのですが、これからはテスト用のwebAppsは
https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
でESModule形式で書いて、
それをいつ変換が完了するかわからない機能により従来のjsに変換されるのを待ち、
それを参照する利用者向けのExampleを、それぞれの環境のリポジトリ内のExamplesに従来の形で開発し、用意しなければならないのですよね？　これはかなり面倒です。待ち時間とか作業量とか考えると、無視できない煩雑さが発生しますね。

あ、その意味で、
https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
は、ネーミングをTestsに変えた方が良いと思います。

やはりもしESM化するならば、利用者向けのExamplesも含めて一斉にすべきと思います。（もちろん利用者向けのESMの説明も整備したうえで）それまではESM化は先送りする。

利用者向けのExamplesは誰かが別途　新規ドライバが登録されるたびに各環境用のものをこまめにケアして用意（こちらも当然そのたびにテストが必須）してくれるというのであれば良いのかもしれませんが、それは難しいと思います。

特にバグレポートがきた時の対応を考えると・・・
ドライバ開発者と、利用者の間で別々のコードでバグの検証をするわけにはいきませんから、利用者が個々の環境のExamplesをベースにして問題の報告をいただくことになると思います。
それは
https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
とはメインもドライバも違うコードですから、結局テストも2回（利用者向けのExamplesと、ドライバ開発者の使う上記URLのESMのwebApps)走らせないとならないですよね。

実際にこのところPCA9685のドライバとMPU9250のドライバのデバッグをして登録する作業をしましたが、これは厳しいと思いました。（両方ともmjsではなくjsの方を書き換えてしまいましたし・・・）

dynamis · 2020-12-10T07:28:48Z

いつ変換が完了するかわからない機能により従来のjsに変換されるのを待ち、...

いえ、開発・デバッグする時点から ESM で書き、サンプルアプリ (example) もその mjs ファイルを直接 import する (<script type=module> で読むように書けば、そのまま何も変換されずに実行されます。

変換はあくまでも従来の <script type=javascript> で読み込む場合のためだけに必要で、開発・試験中に利用することは無いものです。

メインもドライバも違うコードですから、結局テストも2回

ESM (mjs) を import で読むのも変換後の CMD (js) を読むのもアプリの挙動としては一致するので、テストアプリの中身を変えない限りはドライバの変更をしても変換後の方の再テストは不要です。

とはいえ、ドライバだけでなく example アプリ側も一度リリースしてからも何度も書き換えながらやるということであれば、リリース毎に手間が発生してしまうのは仰るとおりです。

それを避けるためにはやはり仰るとおり、tutorial/example もまとめて全部 ESM に移行する、そのために説明をちゃんと書いていくという方針になるかと思います。

satakagi · 2020-12-10T07:33:09Z

変換はあくまでも従来の <script type=javascript> で読み込む場合のためだけに必要で、開発・試験中に利用することは無いものです。

あ、これは理解できていると思います。問題にしているのは、利用者が使用するExamplesの方（RPiとかmicrobitとかのリポジトリの方に同梱されている方）です。
こちらは、従来の<script type=javascript>で読み込む形で当面続けるならば、こちらのテストは必要ですよね。

とはいえ、ドライバだけでなく example アプリ側も一度リリースしてからも何度も書き換えながらやるということであれば、リリース毎に手間が発生してしまうのは仰るとおりです。

そうですね。たとえば、先ほどMPU6500のドライバにgetTemperature()という機能を追加しました。これのテストは
https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
の中において、<script type=module>で読むESMでつくります。

しかし、Rpi3の中の利用者用のExamples
https://github.com/chirimen-oh/chirimen/tree/master/gc/contrib/examples
の中の該当するExamplesにもgetTemperature()を使ったコードに書き換えておくべきですよね。
結果として、開発が二重化します。

tutorial/example もまとめて全部 ESM に移行でないと、ちょっと私だけでは面倒見れないように思いますね。

もしくは、これから新しく追加するデバイスについては、
https://github.com/chirimen-oh/chirimen/tree/master/gc/contrib/examples
の中だけでなく、
利用者用のRpi3の中のExamplesも他の環境のなかのExamplesについても、ESMでOKとする。（利用者用のExamplesがESM使ったものとっ従来のものが混在してしまうのをOKとする）　加えて、仮にデバイスの開発＆テストをRPi以外の環境で行っていた場合でも
https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
の中に入れてしまってもOKにする。

利用者用のExamplesは、このhttps://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
にあるものをごっそりコピーするだけでOKとし、テストは省略する。

＃結果的には「なし崩し的な」ESMへの全面移行　ということです^^;

これなら対応できるかも。

dynamis · 2020-12-10T07:52:22Z

そうですね、仰るとおり

drivers example
- chirimen-drivers/tree/master/examples
user example
- chirimen-oh/chirimen/tree/master/gc
- chirimen-micro-bit/tree/master/examples

が分かれてて両方更新し続けるのが辛いのが問題ですね。

実際今は driver の修正以外は user example 側だけメンテ更新されてることもあるが、driver の機能拡張となると user example にも反映したいし... などとなっていると思います。(ホントに必要な時だけ or ちゃんと覚えてるときだけ両対応という感じでやってるのが現状という気がします)

これから新しく追加するデバイスについては、driver example の中だけでなく、利用者用のRpi3の中のExamplesも他の環境のなかのExamplesについても、ESMでOKとする。（利用者用のExamplesがESM使ったものとっ従来のものが混在してしまうのをOKとする）　加えて、仮にデバイスの開発＆テストをRPi以外の環境で行っていた場合でも driver example に入れる

はい。今までのコーディングルール変更も、可能なときはある程度一括して実施しているが、順次段階的に直しているものなどもあったりするので、方式が複数あるよと言うことを説明、SHT30 だけ (grove もチュートリアルの該当ページだけ残したように) 両方用意するが他は段階的に移行などはあり得ると思います。

もちろん、時間が取れるタイミングで機能追加など無いデバイスもどんどん移行させていき、適当なタイミングで tutorial 標準も ESM 中心にするというような。

dynamis · 2020-12-10T08:05:40Z

note: チュートリアルを ESM (mjs 直接読み込み) に移行する場合 jsbin/jsfiddle という ESM 非互換環境が邪魔だったのだが CSB に移行してめでたく deprecated (2019 アーカイブに移行) させたので、チュートリアル/example を ESM 化する邪魔者は多分もう無い。

satakagi · 2020-12-10T08:19:52Z

CHIRIMEN RPi3はスタンドアロンで動かしたいというニーズがあったのでExamplesがあるけれど、
micro:bitがそもそもそういうケースが考えられないので、chirimen-microbitの中のExamplesは廃止して、chirimen-driversの中の
https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
の該当するものに直リンク張るだけにすべきですね。
それに加えて、CHIRIMEN RPi3のexamplesも　何か自動的に
https://github.com/chirimen-oh/chirimen-drivers/tree/master/examples
の該当するものをコピーされるようにするだけにしておければ、二重化が防げますか。
実際今もpolyfillとかdriverはそういう感じなのですよね？

satakagi · 2020-12-17T03:10:27Z

@dynamis 　基本的にモジュールに全面移行するとなったので、拡張子でmjsを使う必要性は薄い（jsのままにすべき）と思うのですがどうでしょう。
すくなくとも、現在のCHIRIMEN RPi環境のローカルウェブサーバや、私の使っているホスティングではmjsに適切なmimeタイプが設定されず、その結果ロードエラーになります。　ほとんどのケースでmjsのための適切な設定を追加してあげる必要があり、これは今後色々なところで動かないトラブルを起こすことになると思います。

sizuhiko · 2020-12-17T03:13:57Z

これの話ですね
https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide/Modules#%E4%BD%99%E8%AB%87_%E2%80%94_.mjs_%E5%AF%BE_.js

kou029w · 2020-12-17T04:33:56Z

私は拡張子を.jsとすることに異論ありません。
注意する点といたしましては Node.js では .mjs でない場合 package.jsonファイル "type" フィールドの値を "module" と明示的に指定しておかなければ ES Modules であることを認識しなくなるという点です。

例: 下記のように"type": "module" を書き加えることによってパッケージのエントリーポイントである index.js が Node.js v14以降であれば ES Modules であると認識されるため望ましい

{
  "main": "index.js",
  "type": "module",
}

kou029w · 2020-12-19T11:50:12Z

.mjs → .js に改名しました
package.json の type フィールドもエントリーポイントがESMなものに関しては module と指定しました

dynamis · 2020-12-21T05:11:24Z

注意する点といたしましては Node.js では .mjs でない場合 package.jsonファイル "type" フィールドの値を "module" と明示的に指定しておかなければ ES Modules であることを認識しなくなるという点です。

逆に言えばこれだけでしたよね。

過渡期の課題に対するものとして .mjs だったもので、既に Node 14 以降なら package.json で指定すれば済む世界になってきてること、CHIRIMEN のメインは browser 側の利用と思うと js にするという対応で良い (良かった) と思います。

kou029w added the question Further information is requested label Dec 10, 2020

satakagi added documentation Improvements or additions to documentation enhancement New feature or request labels Dec 10, 2020

satakagi mentioned this issue Dec 10, 2020

ES Module の書き方 (モジュール以前のブラウザコードから ES Module への移行方法) を説明する #95

Open

kou029w assigned satakagi Dec 19, 2020

mjsって何でしょう？ #94

mjsって何でしょう？ #94

Comments

satakagi commented Dec 9, 2020 • edited Loading

gurezo commented Dec 9, 2020

kou029w commented Dec 10, 2020

kou029w commented Dec 10, 2020 • edited Loading

kou029w commented Dec 10, 2020 • edited Loading

satakagi commented Dec 10, 2020 • edited Loading

kou029w commented Dec 10, 2020

kou029w commented Dec 10, 2020

kou029w commented Dec 10, 2020 • edited Loading

satakagi commented Dec 10, 2020

satakagi commented Dec 10, 2020

kou029w commented Dec 10, 2020 • edited Loading

kou029w commented Dec 10, 2020

satakagi commented Dec 10, 2020 • edited Loading

kou029w commented Dec 10, 2020

kou029w commented Dec 10, 2020

satakagi commented Dec 10, 2020 • edited Loading

satakagi commented Dec 10, 2020

kou029w commented Dec 10, 2020

kou029w commented Dec 10, 2020

satakagi commented Dec 10, 2020 • edited Loading

satakagi commented Dec 10, 2020

kou029w commented Dec 10, 2020

kou029w commented Dec 10, 2020 • edited Loading

satakagi commented Dec 10, 2020 • edited Loading

satakagi commented Dec 10, 2020

satakagi commented Dec 10, 2020 • edited Loading

dynamis commented Dec 10, 2020

CHIRIMEN 利用者

ドライバ開発者

dynamis commented Dec 10, 2020 • edited Loading

dynamis commented Dec 10, 2020

dynamis commented Dec 10, 2020

satakagi commented Dec 10, 2020 • edited Loading

dynamis commented Dec 10, 2020

satakagi commented Dec 10, 2020 • edited Loading

dynamis commented Dec 10, 2020 • edited Loading

dynamis commented Dec 10, 2020

satakagi commented Dec 10, 2020 • edited Loading

satakagi commented Dec 17, 2020

sizuhiko commented Dec 17, 2020

kou029w commented Dec 17, 2020 • edited Loading

kou029w commented Dec 19, 2020

dynamis commented Dec 21, 2020 • edited Loading

satakagi commented Dec 9, 2020 •

edited

Loading

kou029w commented Dec 10, 2020 •

edited

Loading

kou029w commented Dec 10, 2020 •

edited

Loading

satakagi commented Dec 10, 2020 •

edited

Loading

kou029w commented Dec 10, 2020 •

edited

Loading

kou029w commented Dec 10, 2020 •

edited

Loading

satakagi commented Dec 10, 2020 •

edited

Loading

satakagi commented Dec 10, 2020 •

edited

Loading

satakagi commented Dec 10, 2020 •

edited

Loading

kou029w commented Dec 10, 2020 •

edited

Loading

satakagi commented Dec 10, 2020 •

edited

Loading

satakagi commented Dec 10, 2020 •

edited

Loading

dynamis commented Dec 10, 2020 •

edited

Loading

satakagi commented Dec 10, 2020 •

edited

Loading

satakagi commented Dec 10, 2020 •

edited

Loading

dynamis commented Dec 10, 2020 •

edited

Loading

satakagi commented Dec 10, 2020 •

edited

Loading

kou029w commented Dec 17, 2020 •

edited

Loading

dynamis commented Dec 21, 2020 •

edited

Loading