問題タブ [dependency-resolution]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
0 に答える
155 参照

npm - JS パッケージにはシュリンクラップが必要ですか?

npm shrinkwrapを使用すると、依存関係をロックダウンして、アプリケーションの複製可能なビルドを保証するのに役立つことを理解しています。

私の質問は、アプリケーションの代わりにモジュールを構築している場合はどうなるでしょうか? モジュールの各リリースには、npm-shrinkwrap.json? いくつかのオープン ソース モジュールを調べましたが、それらのリポジトリでそれらを見たことはありません (たとえば、 expressreactchaiasync )。

私の理解では、互換性のあるバージョンを統合することによって npm (>=3) が提供する利点があります。たとえば、pkg-a が lodash に依存し^4.0.0、pkg-b が lodash^4.3.5に依存している場合、最新の lodash 4 リリースの単一のコピーがインストールされます。しかし、pkg-a と pkg-b の両方がシュリンクラップを作成した場合、それらは完全に互換性のあるリリースであっても、まったく同じバージョンの lodash に対応していない可能性が高く、ライブラリの 2 つのコピーをインストールする必要があります。

シュリンクラップを含めないことの欠点は、ライブラリの作成者が、他のアプリケーションによって依存されるパッケージを構築していることであり、その依存関係 (または依存関係の依存関係、再帰的に) のいずれかが重大な変更をリリースすると、いつでも壊れる可能性があります。マイナーまたはパッチ リリース。また、依存関係の依存関係が壊れた場合、ライブラリの作成者がシュリンクラップを公開するために保存できることは何もありません。

たとえば、私のライブラリがrequestに依存しており、それがhawkに依存していて、hawk がパッチ リリースで重大な変更をリリースした場合、正確なバージョンの request にロックダウンしてもライブラリは修正されません。私のライブラリを修正するには、hawk の正確なバージョンを絞り込むシュリンクラップを公開する必要があります。

これは長くなりつつありますが、Nodeモジュールにshrinkwrapを使用するよりも、npmを使用しないことでnpmが提供する利点を利用する方が良いという議論があるかどうかを理解しようとしています.

0 投票する
1 に答える
1135 参照

scala - SBT の推移的な依存関係解決の競合

推移的な依存関係を解決する SBT に問題があります。

エラーは次のとおりです。

Geosparkjts2geojson https://github.com/bjornharrtell/jts2geojson/blob/master/pom.xmlはversion の which references jtsを使用しています1.14が、これは除外されており、代わりにカスタム アーティファクトを使用しています。JTSPlus名前空間にまだ存在し、com.vividsolutionsいくつかの追加のメソッド、つまり上記にないメソッドを提供するものは呼び出されます。

最新版はhttps://github.com/geotools/geotools/blob/master/pom.xml#L752-L754geotools 17で使用していますjts1.13

追加の必要な機能を提供する geotoolsから置き換えるcom.vividsolution.jtsorg.datasyslab.jtsplus必要があります。これを実現するにはどうすればよいですか?

Mavenで:

動作するはずですが、SBT の場合は

修正しませんでした。実際、dependencyGraph を使用すると、SBT がまだバージョン 1.13 の通常の jts をプロジェクト全体に適用していることがわかります。

依存関係を修正して元の JTS バージョンを適切に除外するにはどうすればよいですか?

私のbuild.sbtは次のようになります

0 投票する
1 に答える
6732 参照

gradle - 推移的な依存関係の gradle force バージョンが機能しない。除外、上書き、または強制は適用されないようです

推移的な依存関係と競合しています。オーバーライド、除外、または強制は役に立ちません。適切なバージョンのライブラリを jar に入れるには、他に何ができますか? 完全なコードはありません。https://github.com/geoHeil/gradle-dependency-resolutionが見つかりましたが、その主要部分を以下に説明します。

問題の説明

実行中

geomesa の依存関係 (タイプセーフ/lightbend 構成ライブラリの古いバージョンを取り込む) を無効にします。

そしてjarを実行する

出力

依存関係を有効にする場合:

それは失敗します

これは構成ライブラリの古いバージョンに関連していますが、タイプセーフな構成で NoSuchMethodError を解決するにはどうすればよいですか? . 次の方法でも確認されました。

推移的な依存関係を目的のバージョンの 1.3.3 に修正するにはどうすればよいですか?

私のソリューション

設定しようとしています:

jar を再実行すると、同じ問題で再び失敗します。

また、次のような制約https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:dependency_constraints :

またはhttps://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:enforcing_dependency_versionのような力を使用する:

または好き:

正しいバージョンを提供しません。

結果

すべてのバリアントが同じエラーで失敗します

なにが問題ですか?目的のバージョンを強制する方法が必要です。