プロジェクトのlib/
dirをGitにチェックインすべきではないことを考えると、プロジェクトに含まれるファイルは(ビルドプロセスから)派生ファイルであるためです。プロジェクトのgithubからパッケージをインストールするとき(開発中など)、lib/
dirは存在しないため、パッケージのpackage.json
のmain
フィールドが(たとえば)lib/index.js
、これらのファイルはリポジトリ内に存在せず、したがってnode_modules
にインストールされたパッケージ内に存在するため、インポート時にパッケージをコンパイルできません。これは、パッケージを(リリース前と同じように)ビルドする必要があることを意味し、今回はlib
ディレクトリ(またはビルドプロセス中に生成される他のファイル)がモジュールのディレクトリに追加されるようにローカルでのみです。
package.json
ファイルのbuild
フィールド内にscripts
スクリプトがあると仮定すると、パッケージは、次の状況でこれを自動的に実行するように構成できます。 githubからのみインストールされますか?そうでない場合、githubからインストールしたときにビルドされるようにするための最良のアプローチは何ですか?
prepublish
、prepublishOnly
、およびprepare
のライフサイクルフックがありますが、インストールのソースを区別する方法がないため、この問題に対する答えはありません。 。要するに、はい、インストール時にビルドすることはできますが、githubからのみインストール時にビルドすることはできません。 npmからインストールするときにビルドを強制する理由がないだけでなく、さらに重要なことに、開発の依存関係はインストールされません(たとえば、ビルドに不可欠なbabel
)。
この問題に対処するための1つの戦略を知っています。
lib/
ディレクトリを.gitignore
から削除してチェックインします。lib/
dirを.gitignore
に追加し、gitからdirを削除します。しかし、それは理想とはほど遠いものです。ただし、これはgithookで自動化できると思います。したがって、プロジェクトをマスターするためにプッシュするたびに、ビルドして別のブランチにプッシュします。
NPMのGithubには、解決策のない 未解決の問題 があります-ソリューションを必要とする多くの人々。この問題から、prepare
を使用しても答えにならないことは明らかです。
私のユースケースは、他の多くのプロジェクトで使用されるモジュールを開発していることです。コードベースを更新するたびにリリースをNPMにプッシュすることなく、モジュールの最新バージョンを使用したい-準備ができたらリリースをプッシュしたくないが、libの最新バージョンを使用する必要があるGithubにあります。
注:また、この問題に関するNPMのサポートに連絡し、問題が発生した場合は回答を追加します。
私は質問を適切に理解していませんでした。以下は私が書いたものですが、少しトピックから外れています。とりあえず、リポジトリからインストールするときにbuild.jsonlyを実行する場合:
リポジトリ内のファイル:
.gitignore
.npmignore
ThisIsNpmPackage
build.js
package.json
.gitginore
:
ThisIsNpmPackage
.npmignore
:
!ThisIsNpmPackage
Package.jsonで:
"scripts": {
"install": "( [ ! -f ./ThisIsNpmPackage ] && [ ! -f ./AlreadyInstalled ] && echo \"\" > ./AlreadyInstalled && npm install . && node ./build.js ) || echo \"SKIP: NON GIT SOURCE\""
}
アイデアは、レポジトリでファイルThisIsNpmPackage
を使用可能にすることですが、npmパッケージでは使用できません。
インストールフックは、ThisIsNpmPackage
が存在するかどうかを確認するための単なるスクリプトです。はいの場合、npm install .
を実行します(これにより、devDependencies
が確保されます。ファイルAlreadyInstalled
が生成され、無限ループが防止されます(npm installは再帰的にインストールフックを呼び出します)
公開するときは、git Push
とnpm publish
を行います
npmパブリッシュはCIツールを介して自動化できることに注意してください-githooks
ファイルThisIsNpmPackage
を使用したこの小さなハックにより、ソース検出が利用可能になります。
npm install dumb-package
の呼び出し結果:
「スキップ:非GITソース」
npm install https://github.com/styczynski/dumb-package
の実行
ファイルが作成されます
ここで直面している主な問題は次のとおりです。
npm publish ...
を毎回行う必要があります
小さなバグを修正してからリポジトリにプッシュしてnpmに公開するのを忘れるのが苦痛な場合があります。約5つのスタンドアロンサブプロジェクトがモジュールに分割されているマイクロサービスベースのプロジェクトで作業していたときに、問題を見つけて修正し、必要なすべての場所で公開するのを忘れてしまい、本当に面倒でした。
lib
をレポジトリにプッシュしたくない
リベースとマージはさらに面倒です。
.gitgnore
の混乱なし
ヘック、私はあなたがレポの中に含めなければならない厄介なファイルを持っているが、それらを決して変更しないか、時には削除する必要があるとき、その問題を知っていますか?それはただの病気です。
@Roy Tinkerが述べたように、インストール時にパッケージがコマンドを実行する機能が存在します。
npmフックを使用して実現できます。
"install": "npm run build"
そして、以下を実行します。
npm install https://github.com/<user>/<package>
編集:
コメントからのOP質問:
しかし、これはnpmからモジュールをダウンロードするすべての人にインストールを実行しますか?これは、npmからモジュールをダウンロードする人にはdev依存関係がインストールされないことを考えると、非常に問題です。アプリのビルドに使用されるライブラリ-babelなどはインストールされません。
注:しかし、パッケージの特定のバージョンが必要な場合(production/dev)dev依存関係の有無にかかわらず、次の方法でインストールできます。
npm install --only=dev
--only = {prod [uction] | dev [elopment]}引数により、NODE_ENVに関係なく、devDependenciesのみまたはnon-devDependenciesのみがインストールされます。
私の意見では、より良い解決策は以下を使用することです。
npm install <git remote url>
そして、package.json内で以下を指定します。
"scripts": {
"prepare": "npm run build"
}
インストールされるパッケージに準備スクリプトが含まれている場合、パッケージがパッケージ化およびインストールされる前に、その依存関係とdevDependenciesがインストールされ、準備スクリプトが実行されます。
例:
npm install git+https://[email protected]/npm/npm.git
そこのnpmドキュメントを読んでください: npm install
それは一種の悪い習慣ですが、知っておくと良いでしょう。
時々(Electron frameworkの場合、さまざまな条件に応じて他の外部パッケージまたはリソース/モジュールをインストールする必要があります)。
これらの場合、プロキシアイデアが使用されます。
あなたの場合prepare scriptで十分ですが、時々役に立つかもしれないので、このオプションは残しておきます。
アイデアは、モジュールを記述し、install kookを記述することです:
"scripts": {
"install": "<do the install>"
}
このシナリオでは、そこに配置できます。
npm install . && npm run build
とにかくすべてのdevDependenciesをインストールします(前述の準備ケースのように)が、それはちょっとしたハッキングです。
本当のハッキングを行いたい場合:
"scripts": {
"install": "curl -L -J -O \"<some_url>\""
}
-nixコマンドcurl
を使用して手動でファイルをダウンロードします
それは避けるべきですが、各プラットフォーム用の巨大なバイナリファイルがあるモジュールの場合のオプションであり、それらをすべてインストールしたくありません。
バイナリをコンパイルしたElectronの場合のように(それぞれ別のプラットフォーム用)
だから、人々はinstall package
やinstall package-linux
などではなくpackage-window
を作ってほしい。
そのため、package.json
でカスタムinstall
スクリプトを提供します
{
...
"scripts": {
"install": "node ./install_platform_dep.js"
}
}
その後、module
をインストールすると、install_platform_dep.js
スクリプトが実行されます。 install_platform_dep.js
の中に配置します:
// For Windows...
if(process.platform === 'win32') {
// Trigger Windows module installation
exec('npm install fancy-module-windows', (err, stdout, stderr) => {
// Some error handling...
}
} else if ... // Process other OS'es
そして、これは純粋に手動の方法ですべてをインストールします。
注:もう一度このアプローチはプラットフォーム依存のモジュールで使用でき、それを使用する場合はおそらくコードの設計上の問題です。
私の頭に浮かぶのは、私が実際に長い間使用していたソリューションです(CIサービスを使用した自動構築)。
CIサービスの主な目的は、ブランチにプッシュするとき、またはリポジトリで他のアクションを実行するときにコードをtest/build/publishすることです。
アイデアは、設定ファイル(travis.ymlまたは。gitlab-ci.ymlなど)を提供し、ツールが世話をすることです。残りの。
あなたが本当にプロジェクトにライブラリを含めたくない場合は、CIがすべてを行うことを信頼してください:
今、私は自分のプロジェクトで(趣味の一部として)Webページを作成しているGitlabに取り組んでいます。プロジェクトをビルドするGitlab構成は次のようになります。
image: tetraweb/php
cache:
untracked: true
paths:
- public_html/
- node_modules/
before_script:
- apt-get update
stages:
- build
- test
- deploy
build_product:
stage: build
script:
- npm run test
build_product:
stage: build
script:
- npm run build
deploy_product:
stage: deploy
script:
- npm run deploy
メインブランチにマージすると、次のイベントが発生します。
build
ステージを実行しますtest
ステージが起動しますtest
フェーズに問題がなければ、最終的にステージdeploy
がトリガーされますスクリプトは、実行されるUNIXコマンドのリストです。
Configで任意のDockerイメージを指定できるため、実際にはいくつかの(またはインストールされていない)ツールがインストールされている任意のUnixバージョンを使用します。
パッケージがあります deploy-to-git 目的のリポジトリブランチにアーティファクトをデプロイします。
または、ここ(Travis CIの場合)にアーティファクトをリポジトリに公開する構成の一部:
(自分で使用しました)
その後、もちろん、CIを実行できます:
npm publish .
CIはUnixコマンドを実行するので、次のことができます(少なくともCIプロバイダーの束):
では私は何をすべきか:
私はコミットし、プッシュし、ツールが私が望む他のすべてを行うようにします。
その間、私は他の変更を行い、1〜10分後に更新レポートをメールで受け取ります。
そこには多くのCIプロバイダーがあります:
ここに、他のプロジェクトの別の例を添付します(。travis.yml):
language: generic
install:
- npm install
script:
- chmod u+x ./utest.sh
- chmod u+x ./self_test/autodetection_cli/someprogram.sh
- cd self_test && bash ../utest.sh --ttools stime --tno-spinner
CIを設定してパッケージをプッシュおよび公開する場合、ehを心配することなく、常にコードの最新バージョンを使用するようにしてください。このコマンドも実行する必要があります。 。問題。
CIプロバイダーのいずれかを選択することをお勧めします。
最高のものは何百もの能力を提供します!
パブリッシュ、テスト、ビルドの各段階を自動的に行うことに慣れると、人生を楽しむのにどのように役立つかがわかります!
次に、自動スクリプトを使用して別のプロジェクトを開始するには、構成をコピーするだけです!
私の意見ではnpm prepare scriptはオプションです。
他の人も試してみることもできます。
説明されている各方法には欠点があり、達成したい内容に応じて使用できます。
いくつかの選択肢を提供したいのですが、それらのいくつかがあなたの問題に合うことを願っています!
Package.jsonファイルのスクリプトフィールド内に
build
スクリプトがあると仮定すると、この状況でこれを自動的に実行するようにパッケージを構成できますか?
はい。あなたがする必要がある2つのことがあります:
システムがnpm
またはyarn
を使用してGitHubからパッケージをインストールしていることを確認してください。このパッケージが別のパッケージの依存関係である場合、package.json
のバージョン番号の代わりにGitHub URLを使用できます。それ以外の場合、次のコマンドが機能します。
npm install https://github.com/YourUser/your-package
特定のタグまたはブランチの後にいる場合は、/tags/v1.0.0
などをURLの末尾に追加できます。
モジュールのpackage.json
のscripts
に次を追加します。
"install": "npm run build"
install
は、モジュールのインストール後にパッケージマネージャーが実行するフックです。 (preinstall
およびpostinstall
も-ドキュメントを参照)。
それは素晴らしい質問です。信頼できる解決策が認められていないのは残念ですが、以下はうまくいくようです。
.buildme
マーカーファイルを作成し、gitにコミットします。
package.json
:
"files": ["lib"],
"scripts": {
"build": "echo DO WHAT YOU NEED TO BUILD",
"prepack": "[ ! -f .buildme ] || npm run build",
"preinstall": "[ ! -f .buildme ] || npm run build"
},
ここで注意すべき点があります。
特別な.buildme
マーカーファイルは、"files"
キーを使用するか、.npmignore
を介してnpmパッケージから除外する必要があります。
パブリッシュするとprepack
フックが実行されます(prepublishOnly
も機能する可能性がありますが、prepack
、npm pack
を使用すると正しいtarballが生成されるのは素晴らしいことです)。
Npmからインストールする場合、preinstall
は実行されますが、.buildme
がないため、何も実行されません([ ! -f .buildme ]
句のおかげ)。
Githubからインストールする場合、.buildme
は存在します。 npm6では、prepack
フックがビルドを実行し(そして.buildme
なしでパッケージを生成します)、preinstall
は何もしません。 yarn 1.12では、preinstall
がビルドを行います。
Githubから更新されたバージョンをインストールすると、preinstall
が再度実行され、再度ビルドされます。
注:githubからインストールする場合、ビルドが機能するために十分なパッケージのdevDependencies
が既にインストールされているかどうかは、インストールする人次第です。 (このソリューションはdevDependencies
の自動インストールを試みません。)
それでおしまい。 npm 6とyarn 1.12のさまざまな組み合わせで動作するようです。
prepare
は正しい方法ですソースファイルを含むリポジトリがあるが、それを使用するために「ビルド」ステップが必要な場合、prepare
はすべての場合に必要なことを正確に行います(npm 4以降)。
prepare
:パッケージをパックして公開する前に、引数なしでローカルのnpm install
で、およびgit依存関係をインストールするときに両方を実行します。
ビルドの依存関係をdevDependencies
に入れることもでき、prepare
が実行される前にインストールされます。
このメソッドを使用する私のパッケージの 例 です。
.gitignore
の問題このオプションには、多くの人を惹きつける問題が1つあります。依存関係を準備するとき、NpmとYarnはpackage.json
のfiles
セクションにリストされているファイルをonlyで保持します。
files
がデフォルトでインクルードされるすべてのファイルになります であり、完了したと思うかもしれません。簡単に見逃されるのは、.npmignore
mostlyがfiles
ディレクティブandをオーバーライドすることです。.npmignore
が存在しない場合は、.gitignore
が代わりに使用されます。
したがって、健全な人物のように.gitignore
にビルドファイルをリストしている場合、files
にビルドファイルをリストしないでください。また、.npmignore
ファイルを使用しないでくださいprepare
seembroken。
files
を修正してビルドされたファイルのみを含めるか、空の.npmignore
を追加すれば、すべて完了です。