Q&A
前提・実現したいこと
利用しているNPMモジュールが全く更新されず、プルリクエストを送っても最新のEJSに対応してくれないので、forkしたものを修正し、これを自前で公開したい。
発生している問題
- パッケージ名を変えてしまってもよいのか、同名で進めるのが良いのか
- 前者の場合、バージョン番号は1.0.0に戻してしまってもいいのか
- ライセンス情報に開発者の名前があるが、差し替えるべきなのか、併記するべきなのか
- READMEに必ず記載すべきものはあるのか
- 3, 4に記載る名前はハンドルネーム（baananacoffee）でも良いのか
該当のソースコード
fork元： https://github.com/mcmath/ejs-html-loader
修正版： https://github.com/bananacoffee/ejs3-html-loader
試したこと
【1. パッケージ名を変えてしまってもよいのか、同名で進めるのが良いのか。】
について、ejs3.xに対応という意味合いでパッケージ名を変えてみた。
【2. 前者の場合、バージョン番号は1.0.0に戻してしまってもいいのか。】
について、バージョン番号を戻したかったが、過去のコミットやタグが残っているため難しいと感じた。
【3. ライセンス情報に開発者の名前があるが、差し替えるべきなのか、併記するべきなのか。】
について、ひとまず併記とした。
https://github.com/bananacoffee/ejs3-html-loader/blob/master/LICENSE
【4. READMEに必ず記載すべきものはあるのか。】
について、forkであることと、TANKS FORという項目を設けた。
https://github.com/bananacoffee/ejs3-html-loader
【5. 3, 4に記載る名前はハンドルネーム（baananacoffee）でも良いのか】
ひとまずハンドルネームで記載した。
補足情報
今年5月に修正版をプルリクエストしたが、半年近く放置されており、かつ、Qiitaに対応法の記事も記載しているが、それなりに読まれているため、今回の決断に至った。
回答1件
0
ベストアンサー
実際npmにも山のように同じ題材のライブラリが並んで居ますので、
好き勝手にオレオレライブラリを作って公開しても良いと思います。
上記を踏まえて今回のような対応を私が行う事になった場合、
下記のように決定すると思います。
一つの他人の意見として参考にしてみてください。
- パッケージ名を変えてしまってもよいのか、同名で進めるのが良いのか
- 前者の場合、バージョン番号は1.0.0に戻してしまってもいいのか
パッケージ名は変えて良いです。
むしろREADMEの上の方にもっとejs3対応なんだぜ感を前面に押し出した方が良いので
私も「ejs3-html-loader」みたいな名前にしてるでしょう。
もしライブラリの保守対応とかしたくないならば改名は無しが無難ですかね。
作者に頑張って欲しいので「こちらのプロジェクトをフォークしてコミット履歴を足しました」と載せ、
あくまで暫定的なライブラリだということを強調しつつサボる方向に全振りします。
npmのサイトにパブリッシュすると面倒な事になるのは目に見えているので、
README.mdのインストールの項目ではnpm install bananacoffee/ejs3-html-loaderでの導入を紹介するように記述を変えて凌ぐ形にします。
参考記事: Githubまたはローカルのnpm のパッケージをinstallする方法 - Qiita
- ライセンス情報に開発者の名前があるが、差し替えるべきなのか、併記するべきなのか
- READMEに必ず記載すべきものはあるのか
- 3, 4に記載る名前はハンドルネーム（baananacoffee）でも良いのか
元ネタのejs-html-loaderはMITライセンスなので、
適切に取り扱ってください。
とはいえ、MITライセンスは世界一雑なライセンスなので、最低限のとこさえ守っていればライセンス違反にはならないでしょう。
なので取りうる手段は先程の例と同じで、
自分はライブラリのアップデートに対して責任を持つのか持たないかが重要です。
それにより振る舞いを変えていきます。
責任を持つなら自分の名前で記載しなおし！
READMEも前のプロジェクトの事はインスパイア元として一言紹介に留めておき、
ライブラリを見たユーザーが扱える最善の説明書きが記載されているべきですからね。
そもそもテストコードがCoffeeScriptってなんだよES6以降のコードでよくね？
スパッと捨てちゃってES6で書き直そう。
責任を持ちたくないコースで行くなら、あくまで暫定！
フォークして手直ししただけなんだよ感を前面に押し出す感じにすれば良いでしょう。
となればライセンスはいじらず、READMEもちょろっと変えた程度で済ませます。
プルリクエストを読みましたが、
微妙と感じる箇所がいくつかありました。
- プルリクエストの説明書きが空なんだが……
- メソッド勝手に減らしてるけど動作は？
- テストはどういう結果になるの？
作者が音信不通になっている可能性は大いにありえますが、
私がライブラリの開発者だとして、
上記の事を無視したプルリクエストが来ても無視(放置)しちゃうかもしれません。
一番ツッコみたい箇所として
ejs3のcompatible(互換性)を謳っていますがオブジェクトのキーを勝手に削ってますよね？
もしかして、ejs2では動作せずejs3専用なのではないですか？
(この辺私は全然ejsには詳しくなく、試してもないので的外れだったらごめんなさい)
(まぁ、depsってなんやねんいらねえよと思う気持ちもわかる気がする)
ちゃんとejs2でも動作確認して互換性があるなら
プルリクエストの説明書きに真っ先に記載して、
安心させて欲しいなと思ってしまいます。
また動作が変わりますが、テストコードは動きますか？
コレにより失敗するテストがあるなら、テストコードを修正するのもプルリクエスト作成者の義務です。
npm run testコマンドを実行してテストも走らせてみてください。
その上でやはり説明書きにテスト結果に関しても軽く触れて欲しいですね。
ejs2とejs3を組み込んだテストコードも用意してテストが通る事を確認しています、みたいな。
ここまで完璧にやれていれば、質問者さんに全く落ち度はないと思います。
作者が蒸発したので、npmで新しいライブラリ名で公開するかという感じになりますね。
投稿2020/10/12 09:00
編集2020/10/12 09:31
総合スコア21158
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2020/10/14 01:14 編集