今回は、
Subpath exports
からです。
Subpath exports
When using the "exports" field, custom subpaths can be defined along with the main entry point by treating the main entry point as the "." subpath:
「exports」フィールドを使用する場合、メイン・エントリー・ポイントを「.」サブパスとして扱うことにより、メイン・エントリー・ポイントとともにカスタム・サブパスを定義できます。
{
"exports": {
".": "./index.js",
"./submodule.js": "./src/submodule.js"
}
}
Now only the defined subpath in "exports" can be imported by a consumer:
コンシューマがインポートできるのは、「exports」で定義されたサブパスだけになりました。
import submodule from 'es-module-package/submodule.js';
// Loads ./node_modules/es-module-package/src/submodule.js
While other subpaths will error:
他のサブパスではエラーが発生します:
import submodule from 'es-module-package/private-module.js';
// Throws ERR_PACKAGE_PATH_NOT_EXPORTED
Extensions in subpaths
サブパス内の拡張
Package authors should provide either extensioned (import 'pkg/subpath.js') or extensionless (import 'pkg/subpath') subpaths in their exports. This ensures that there is only one subpath for each exported module so that all dependents import the same consistent specifier, keeping the package contract clear for consumers and simplifying package subpath completions.
パッケージの作成者は、拡張された(import'pkg/subpath.js')または拡張されていない(import'pkg/subpath')サブパスをエクスポートに提供する必要がある。
これにより、エクスポートされたモジュールごとにサブパスが1つだけになるため、すべての依存関係が同じ一貫した指定子をインポートできるようになり、消費者にとってパッケージ契約が明確になり、パッケージのサブパス補完が簡素化される。
Traditionally, packages tended to use the extensionless style, which has the benefits of readability and of masking the true path of the file within the package.
従来、パッケージは拡張子のないスタイルを使用する傾向がありました。
これには、読みやすさと、パッケージ内のファイルの実際のパスをマスクするという利点があります。
With import maps now providing a standard for package resolution in browsers and other JavaScript runtimes, using the extensionless style can result in bloated import map definitions. Explicit file extensions can avoid this issue by enabling the import map to utilize a packages folder mapping to map multiple subpaths where possible instead of a separate map entry per package subpath export. This also mirrors the requirement of using the full specifier path in relative and absolute import specifiers.
インポート・マップがブラウザやその他のJavaScriptランタイムでパッケージ解決の標準を提供するようになったため、拡張子のないスタイルを使用すると、インポート・マップ定義が肥大する可能性があります。
明示的なファイル拡張子を使用すると、パッケージ・サブパス・エクスポートごとに個別のマップ・エントリを使用するのではなく、インポート・マップでパッケージ・フォルダ・マッピングを使用して複数のサブパスをマッピングできるようにすることで、この問題を回避できます。
これは、相対および絶対インポート指定子で完全指定子パスを使用する要件も反映しています。
Exports sugar
If the "." export is the only export, the "exports" field provides sugar for this case being the direct "exports" field value.
「.」エクスポートが唯一のエクスポートである場合、「exports」フィールドは、直接の「exports」フィールド値であるこの場合のシュガーを提供します。
can be written:
次のように記述できます。
{
"exports": "./index.js"
}
Subpath imports
In addition to the "exports" field, there is a package "imports" field to create private mappings that only apply to import specifiers from within the package itself.
「exports」フィールドに加えて、パッケージ自体の中からインポート指定子にのみ適用されるプライベートマッピングを作成するためのパッケージ「imports」フィールドがある。
Entries in the "imports" field must always start with # to ensure they are disambiguated from external package specifiers.
"imports"フィールドのエントリは、外部のパッケージ指定子と区別するために、常に#で始まる必要があります。
For example, the imports field can be used to gain the benefits of conditional exports for internal modules:
たとえば、インポートフィールドを使用して、内部モジュールの条件付きエクスポートのメリットを得ることができます。
// package.json
{
"imports": {
"#dep": {
"node": "dep-node-native",
"default": "./dep-polyfill.js"
}
},
"dependencies": {
"dep-node-native": "^1.0.0"
}
}
where import '#dep' does not get the resolution of the external package dep-node-native (including its exports in turn), and instead gets the local file ./dep-polyfill.js relative to the package in other environments.
ここで、import'#dep'は、外部パッケージdep-node-native(順番にそのエクスポートを含む)の解決を取得せず、代わりに他の環境のパッケージに関連するローカルファイル./dep-polyfill.jsを取得する。
Unlike the "exports" field, the "imports" field permits mapping to external packages.
"exports"フィールドとは異なり、"imports"フィールドでは外部パッケージへのマッピングが可能です。
The resolution rules for the imports field are otherwise analogous to the exports field.
インポートフィールドの解決ルールは、それ以外の点ではエクスポートフィールドと類似している。
Subpath patterns
For packages with a small number of exports or imports, we recommend explicitly listing each exports subpath entry. But for packages that have large numbers of subpaths, this might cause package.json bloat and maintenance issues.
エクスポートまたはインポートの数が少ないパッケージでは、各エクスポートサブパスエントリを明示的にリストすることをお勧めします。
ただし、サブパスの数が多いパッケージでは、package.jsonの肥大化とメンテナンスの問題が発生する可能性があります。
For these use cases, subpath export patterns can be used instead:
これらのユースケースでは、サブパスエクスポートパターンを代わりに使用できます。
// ./node_modules/es-module-package/package.json
{
"exports": {
"./features/*.js": "./src/features/*.js"
},
"imports": {
"#internal/*.js": "./src/internal/*.js"
}
}
* maps expose nested subpaths as it is a string replacement syntax only.
*マップは文字列置換構文のみであるため、ネストされたサブパスを公開します。
All instances of * on the right hand side will then be replaced with this value, including if it contains any / separators.
次に、右側の*のすべてのインスタンスは、/セパレータを含む場合も含めて、この値で置き換えられる。
import featureX from 'es-module-package/features/x.js';
// Loads ./node_modules/es-module-package/src/features/x.js
import featureY from 'es-module-package/features/y/y.js';
// Loads ./node_modules/es-module-package/src/features/y/y.js
import internalZ from '#internal/z.js';
// Loads ./node_modules/es-module-package/src/internal/z.js
This is a direct static matching and replacement without any special handling for file extensions. Including the "*.js" on both sides of the mapping restricts the exposed package exports to only JS files.
これは、ファイル拡張子の特別な処理を伴わない、直接的な静的マッチングと置換である。
マッピングの両側に「*.js」を含めると、公開されたパッケージのエクスポートはJSファイルのみに制限される。
The property of exports being statically enumerable is maintained with exports patterns since the individual exports for a package can be determined by treating the right hand side target pattern as a ** glob against the list of files within the package. Because node_modules paths are forbidden in exports targets, this expansion is dependent on only the files of the package itself.
静的に列挙可能なエクスポートのプロパティは、エクスポートパターンで維持されます。
これは、パッケージ内のファイルのリストに対して右側のターゲットパターンを**globとして扱うことで、パッケージの個々のエクスポートを決定できるためです。
エクスポートターゲットではnode_modulesパスが禁止されているため、この拡張はパッケージ自体のファイルにのみ依存します。
To exclude private subfolders from patterns, null targets can be used:
プライベートサブフォルダをパターンから除外するには、ヌルターゲットを使用できる。
// ./node_modules/es-module-package/package.json
{
"exports": {
"./features/*.js": "./src/features/*.js",
"./features/private-internal/*": null
}
}
import featureInternal from 'es-module-package/features/private-internal/m.js';
// Throws: ERR_PACKAGE_PATH_NOT_EXPORTED
import featureX from 'es-module-package/features/x.js';
// Loads ./node_modules/es-module-package/src/features/x.js
次回は
Conditional exports
から見ていきます。
