@@ -349,21 +349,14 @@ The conditions supported in Node.js condition matching: |
349 | 349 | or ES module file. |
350 | 350 | * `"import"` - matched when the package is loaded via `import` or |
351 | 351 | `import()`. Can be any module format, this field does not set the type |
352 | | - interpretation. _This is currently only supported behind the |
353 | | - `--experimental-conditional-exports` flag._ |
| 352 | + interpretation. |
354 | 353 | * `"node"` - matched for any Node.js environment. Can be a CommonJS or ES |
355 | | - module file. _This is currently only supported behind the |
356 | | - `--experimental-conditional-exports` flag._ |
| 354 | + module file. |
357 | 355 | * `"require"` - matched when the package is loaded via `require()`. |
358 | | - _This is currently only supported behind the |
359 | | - `--experimental-conditional-exports` flag._ |
360 | 356 |
|
361 | 357 | Condition matching is applied in object order from first to last within the |
362 | 358 | `"exports"` object. |
363 | 359 |
|
364 | | -> Setting the above conditions for a published package is not recommended until |
365 | | -> conditional exports have been unflagged to avoid breaking changes to packages. |
366 | | -
|
367 | 360 | Using the `"require"` condition it is possible to define a package that will |
368 | 361 | have a different exported value for CommonJS and ES modules, which can be a |
369 | 362 | hazard in that it can result in having two separate instances of the same |
@@ -456,10 +449,10 @@ ignores) the top-level `"module"` field. |
456 | 449 | Node.js can now run ES module entry points, and a package can contain both |
457 | 450 | CommonJS and ES module entry points (either via separate specifiers such as |
458 | 451 | `'pkg'` and `'pkg/es-module'`, or both at the same specifier via [Conditional |
459 | | -Exports][] with the `--experimental-conditional-exports` flag). Unlike in the |
460 | | -scenario where `"module"` is only used by bundlers, or ES module files are |
461 | | -transpiled into CommonJS on the fly before evaluation by Node.js, the files |
462 | | -referenced by the ES module entry point are evaluated as ES modules. |
| 452 | +Exports][]). Unlike in the scenario where `"module"` is only used by bundlers, |
| 453 | +or ES module files are transpiled into CommonJS on the fly before evaluation by |
| 454 | +Node.js, the files referenced by the ES module entry point are evaluated as ES |
| 455 | +modules. |
463 | 456 |
|
464 | 457 | #### Dual Package Hazard |
465 | 458 |
|
@@ -518,13 +511,8 @@ following conditions: |
518 | 511 |
|
519 | 512 | Write the package in CommonJS or transpile ES module sources into CommonJS, and |
520 | 513 | create an ES module wrapper file that defines the named exports. Using |
521 | | -[Conditional Exports][] via the `--experimental-conditional-exports` flag, the |
522 | | -ES module wrapper is used for `import` and the CommonJS entry point for |
523 | | -`require`. |
524 | | - |
525 | | -> Note: While `--experimental-conditional-exports` is flagged, a package |
526 | | -> using this pattern will throw when loaded unless package consumers use the |
527 | | -> `--experimental-conditional-exports` flag. |
| 514 | +[Conditional Exports][], the ES module wrapper is used for `import` and the |
| 515 | +CommonJS entry point for `require`. |
528 | 516 |
|
529 | 517 | <!-- eslint-skip --> |
530 | 518 | ```js |
@@ -580,13 +568,13 @@ This approach is appropriate for any of the following use cases: |
580 | 568 | * The package stores internal state, and the package author would prefer not to |
581 | 569 | refactor the package to isolate its state management. See the next section. |
582 | 570 |
|
583 | | -A variant of this approach not requiring `--experimental-conditional-exports` |
584 | | -for consumers could be to add an export, e.g. `"./module"`, to point to an |
585 | | -all-ES module-syntax version of the package. This could be used via `import |
586 | | -'pkg/module'` by users who are certain that the CommonJS version will not be |
587 | | -loaded anywhere in the application, such as by dependencies; or if the CommonJS |
588 | | -version can be loaded but doesn’t affect the ES module version (for example, |
589 | | -because the package is stateless): |
| 571 | +A variant of this approach not requiring conditional exports for consumers could |
| 572 | +be to add an export, e.g. `"./module"`, to point to an all-ES module-syntax |
| 573 | +version of the package. This could be used via `import 'pkg/module'` by users |
| 574 | +who are certain that the CommonJS version will not be loaded anywhere in the |
| 575 | +application, such as by dependencies; or if the CommonJS version can be loaded |
| 576 | +but doesn’t affect the ES module version (for example, because the package is |
| 577 | +stateless): |
590 | 578 |
|
591 | 579 | <!-- eslint-skip --> |
592 | 580 | ```js |
@@ -601,16 +589,10 @@ because the package is stateless): |
601 | 589 | } |
602 | 590 | ``` |
603 | 591 |
|
604 | | -If the `--experimental-conditional-exports` flag is dropped and therefore |
605 | | -[Conditional Exports][] become available without a flag, this variant could be |
606 | | -easily updated to use conditional exports by adding conditions to the `"."` |
607 | | -path; while keeping `"./module"` for backward compatibility. |
608 | | - |
609 | 592 | ##### Approach #2: Isolate State |
610 | 593 |
|
611 | 594 | The most straightforward `package.json` would be one that defines the separate |
612 | | -CommonJS and ES module entry points directly (requires |
613 | | -`--experimental-conditional-exports`): |
| 595 | +CommonJS and ES module entry points directly: |
614 | 596 |
|
615 | 597 | <!-- eslint-skip --> |
616 | 598 | ```js |
@@ -695,8 +677,8 @@ Even with isolated state, there is still the cost of possible extra code |
695 | 677 | execution between the CommonJS and ES module versions of a package. |
696 | 678 |
|
697 | 679 | As with the previous approach, a variant of this approach not requiring |
698 | | -`--experimental-conditional-exports` for consumers could be to add an export, |
699 | | -e.g. `"./module"`, to point to an all-ES module-syntax version of the package: |
| 680 | +conditional exports for consumers could be to add an export, e.g. |
| 681 | +`"./module"`, to point to an all-ES module-syntax version of the package: |
700 | 682 |
|
701 | 683 | <!-- eslint-skip --> |
702 | 684 | ```js |
@@ -711,11 +693,6 @@ e.g. `"./module"`, to point to an all-ES module-syntax version of the package: |
711 | 693 | } |
712 | 694 | ``` |
713 | 695 |
|
714 | | -If the `--experimental-conditional-exports` flag is dropped and therefore |
715 | | -[Conditional Exports][] become available without a flag, this variant could be |
716 | | -easily updated to use conditional exports by adding conditions to the `"."` |
717 | | -path; while keeping `"./module"` for backward compatibility. |
718 | | - |
719 | 696 | ## `import` Specifiers |
720 | 697 |
|
721 | 698 | ### Terminology |
|