これは、会社の内部パッケージの1つがリファクタリングを行い、package.jsonのmain
を更新することを忘れずに、エントリポイントをリポジトリ内の別の場所に移動したときに発見されました。 その結果、 npm pack
が問題なく作成され、適切に機能する可能性のないパッケージを公開できるようになりました。
npm pack
場合、したがってnpm publish
が実行される場合
npm pack
は、 main
がtarballに存在することを検証しないため、消費者が使用できないパッケージの作成と公開がいくらか簡単になります。
npm init
そしてデフォルト値ですべてを作成するステップスルー。 このようなpackage.json
取得します{
"name": "npm-repro",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC"
}
npm pack
を実行し、tarballが正常に作成されていることを確認しますnpm notice
npm notice 📦 [email protected]
npm notice === Tarball Contents ===
npm notice 205B package.json
npm notice === Tarball Details ===
npm notice name: npm-repro
npm notice version: 1.0.0
npm notice filename: npm-repro-1.0.0.tgz
npm notice package size: 241 B
npm notice unpacked size: 205 B
npm notice shasum: ca39bc17447e27ef2fd0dea656e0e6b473f310d7
npm notice integrity: sha512-p8tZD8W438r7t[...]7Oo0YMcAoNPzQ==
npm notice total files: 1
npm notice
npm-repro-1.0.0.tgz
index.js
がないため、このパッケージを使用しようとしても機能しません。
npm pack
は、ゼロ以外の終了コードで終了します。これにより、 npm publish
が失敗し、tarballにpackage.json
のmain
が含まれていないパッケージが防止されます。 package.json
レジストリへの公開から。私たちの会社は、私たちの内部レジストリに公開しようとしたときにこれに遭遇しました。
これがnpm-packlist
バグとして適しているかどうかはわかりません。 npm
組織が、2つの間の関心の分離をどのように維持したいかは完全にはわかりません。 つまり、 npm-packlist
、検証を行わずにインクルードを試みる必要のあるファイルのリストを盲目的に返し、 npm-packlist
機能を使用するパッケージで高次の検証を実行するようにします。 ?
これはnpm-packlistの仕事ではなく、どちらかといえばnpm publish
の仕事です。
それは合理的に聞こえます。 なんらかの理由で、私の会社は、発行が正常に完了するかどうかを確認するためのテストとしてnpm pack
を使用することにしました。 npm publish --dry-run
はおそらくより良いチェックです。
最も参考になるコメント
それは合理的に聞こえます。 なんらかの理由で、私の会社は、発行が正常に完了するかどうかを確認するためのテストとして
npm pack
を使用することにしました。npm publish --dry-run
はおそらくより良いチェックです。