@@ -355,21 +355,14 @@ The conditions supported in Node.js condition matching: |
355 | 355 | or ES module file. |
356 | 356 | * `"import"` - matched when the package is loaded via `import` or |
357 | 357 | `import()`. Can be any module format, this field does not set the type |
358 | | - interpretation. _This is currently only supported behind the |
359 | | - `--experimental-conditional-exports` flag._ |
| 358 | + interpretation. |
360 | 359 | * `"node"` - matched for any Node.js environment. Can be a CommonJS or ES |
361 | | - module file. _This is currently only supported behind the |
362 | | - `--experimental-conditional-exports` flag._ |
| 360 | + module file. |
363 | 361 | * `"require"` - matched when the package is loaded via `require()`. |
364 | | - _This is currently only supported behind the |
365 | | - `--experimental-conditional-exports` flag._ |
366 | 362 |
|
367 | 363 | Condition matching is applied in object order from first to last within the |
368 | 364 | `"exports"` object. |
369 | 365 |
|
370 | | -> Setting the above conditions for a published package is not recommended until |
371 | | -> conditional exports have been unflagged to avoid breaking changes to packages. |
372 | | -
|
373 | 366 | Using the `"require"` condition it is possible to define a package that will |
374 | 367 | have a different exported value for CommonJS and ES modules, which can be a |
375 | 368 | hazard in that it can result in having two separate instances of the same |
@@ -462,10 +455,10 @@ ignores) the top-level `"module"` field. |
462 | 455 | Node.js can now run ES module entry points, and a package can contain both |
463 | 456 | CommonJS and ES module entry points (either via separate specifiers such as |
464 | 457 | `'pkg'` and `'pkg/es-module'`, or both at the same specifier via [Conditional |
465 | | -Exports][] with the `--experimental-conditional-exports` flag). Unlike in the |
466 | | -scenario where `"module"` is only used by bundlers, or ES module files are |
467 | | -transpiled into CommonJS on the fly before evaluation by Node.js, the files |
468 | | -referenced by the ES module entry point are evaluated as ES modules. |
| 458 | +Exports][]). Unlike in the scenario where `"module"` is only used by bundlers, |
| 459 | +or ES module files are transpiled into CommonJS on the fly before evaluation by |
| 460 | +Node.js, the files referenced by the ES module entry point are evaluated as ES |
| 461 | +modules. |
469 | 462 |
|
470 | 463 | #### Dual Package Hazard |
471 | 464 |
|
@@ -524,13 +517,8 @@ following conditions: |
524 | 517 |
|
525 | 518 | Write the package in CommonJS or transpile ES module sources into CommonJS, and |
526 | 519 | create an ES module wrapper file that defines the named exports. Using |
527 | | -[Conditional Exports][] via the `--experimental-conditional-exports` flag, the |
528 | | -ES module wrapper is used for `import` and the CommonJS entry point for |
529 | | -`require`. |
530 | | - |
531 | | -> Note: While `--experimental-conditional-exports` is flagged, a package |
532 | | -> using this pattern will throw when loaded unless package consumers use the |
533 | | -> `--experimental-conditional-exports` flag. |
| 520 | +[Conditional Exports][], the ES module wrapper is used for `import` and the |
| 521 | +CommonJS entry point for `require`. |
534 | 522 |
|
535 | 523 | <!-- eslint-skip --> |
536 | 524 | ```js |
@@ -586,13 +574,13 @@ This approach is appropriate for any of the following use cases: |
586 | 574 | * The package stores internal state, and the package author would prefer not to |
587 | 575 | refactor the package to isolate its state management. See the next section. |
588 | 576 |
|
589 | | -A variant of this approach not requiring `--experimental-conditional-exports` |
590 | | -for consumers could be to add an export, e.g. `"./module"`, to point to an |
591 | | -all-ES module-syntax version of the package. This could be used via `import |
592 | | -'pkg/module'` by users who are certain that the CommonJS version will not be |
593 | | -loaded anywhere in the application, such as by dependencies; or if the CommonJS |
594 | | -version can be loaded but doesn’t affect the ES module version (for example, |
595 | | -because the package is stateless): |
| 577 | +A variant of this approach not requiring conditional exports for consumers could |
| 578 | +be to add an export, e.g. `"./module"`, to point to an all-ES module-syntax |
| 579 | +version of the package. This could be used via `import 'pkg/module'` by users |
| 580 | +who are certain that the CommonJS version will not be loaded anywhere in the |
| 581 | +application, such as by dependencies; or if the CommonJS version can be loaded |
| 582 | +but doesn’t affect the ES module version (for example, because the package is |
| 583 | +stateless): |
596 | 584 |
|
597 | 585 | <!-- eslint-skip --> |
598 | 586 | ```js |
@@ -607,16 +595,10 @@ because the package is stateless): |
607 | 595 | } |
608 | 596 | ``` |
609 | 597 |
|
610 | | -If the `--experimental-conditional-exports` flag is dropped and therefore |
611 | | -[Conditional Exports][] become available without a flag, this variant could be |
612 | | -easily updated to use conditional exports by adding conditions to the `"."` |
613 | | -path; while keeping `"./module"` for backward compatibility. |
614 | | - |
615 | 598 | ##### Approach #2: Isolate State |
616 | 599 |
|
617 | 600 | The most straightforward `package.json` would be one that defines the separate |
618 | | -CommonJS and ES module entry points directly (requires |
619 | | -`--experimental-conditional-exports`): |
| 601 | +CommonJS and ES module entry points directly: |
620 | 602 |
|
621 | 603 | <!-- eslint-skip --> |
622 | 604 | ```js |
@@ -701,8 +683,8 @@ Even with isolated state, there is still the cost of possible extra code |
701 | 683 | execution between the CommonJS and ES module versions of a package. |
702 | 684 |
|
703 | 685 | As with the previous approach, a variant of this approach not requiring |
704 | | -`--experimental-conditional-exports` for consumers could be to add an export, |
705 | | -e.g. `"./module"`, to point to an all-ES module-syntax version of the package: |
| 686 | +conditional exports for consumers could be to add an export, e.g. |
| 687 | +`"./module"`, to point to an all-ES module-syntax version of the package: |
706 | 688 |
|
707 | 689 | <!-- eslint-skip --> |
708 | 690 | ```js |
@@ -717,11 +699,6 @@ e.g. `"./module"`, to point to an all-ES module-syntax version of the package: |
717 | 699 | } |
718 | 700 | ``` |
719 | 701 |
|
720 | | -If the `--experimental-conditional-exports` flag is dropped and therefore |
721 | | -[Conditional Exports][] become available without a flag, this variant could be |
722 | | -easily updated to use conditional exports by adding conditions to the `"."` |
723 | | -path; while keeping `"./module"` for backward compatibility. |
724 | | - |
725 | 702 | ## `import` Specifiers |
726 | 703 |
|
727 | 704 | ### Terminology |
|