Core: Move the factory to separate exports #7
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mgol
commented
Jul 7, 2023
mgol
force-pushed
the
exports
branch
2 times, most recently
from
638b3ff to
7a978e6
Compare
Summary of the changes: * define the `exports` field in `package.json`; `jQuery` & `$` are also exported as named exports in ESM builds now * declare `"type": "module"` globally except for the `build` folder * add the `--esm` option to `grunt custom`, generating jQuery as an ECMAScript module into the `dist-module` folder * expand `node_smoke_tests` to test the slim & ESM builds and their various combinations; also, test both jQuery loaded via a path to the file as well as from module specifiers that should be parsed via the `exports` feature * add details about ESM usage to the release package README * run `compare_size` on all built minified files; don't run it anymore on unminified files where they don't provide lots of value * remove the remove_map_comment task; SWC doesn't insert the `//# sourceMappingURL=` pragma by default so there's nothing to strip Fixes jquerygh-4592 Closes jquerygh-5255
Since versions 1.11.0/2.1.0, jQuery has used a module wrapper with one strange addition - in CommonJS environments, if a global `window` with a `document` was not present, jQuery exported a factory accepting a `window` implementation and returning jQuery. This approach created a number of problems: 1. Properly typing jQuery would be a nightmare as the exported value depends on the environment. In practice, typing definitions ignored the factory case. 2. Since we now use named exports for the jQuery module version, it felt weird to have `jQuery` and `$` pointing to the factory instead of real jQuery. Instead, for jQuery 4.0 we leverage the just added `exports` field in `package.json` to expose completely separate factory entry points: one for the full build, one for the slim one. Exports definitions for `./factory` & `./factory-slim` are simpler than for `.` and `./slim` - this is because it's a new entry point, we only expose a named export and so there's no issue with just pointing Node.js to the CommonJS version (we cannot use the module version for `import` from Node.js to avoid double package hazard). The factory entry points are also not meant for the Web browser which always has a proper `window` - and they'd be unfit for an inclusion in a regular script tag anyway. Because of that, we also don't generate minified versions of these entry points. The factory files are not pushed to the CDN since they are mostly aimed at Node.js.
mgol
force-pushed
the
exports-separate-factory
branch
from
307092c to
f7f27e2
Compare
Owner
Author
|
Superseded by jquery#5293 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Since versions 1.11.0/2.1.0, jQuery has used a module wrapper with one strange addition - in CommonJS environments, if a global
windowwith adocumentwas not present, jQuery exported a factory accepting awindowimplementation and returning jQuery.This approach created a number of problems:
jQueryand$pointing to the factory instead of real jQuery.Instead, for jQuery 4.0 we leverage the just added
exportsfield inpackage.jsonto expose completely separate factory entry points: one for the full build, one for the slim one.Exports definitions for
./factory&./factory-slimare simpler than for.and./slim- this is because it's a new entry point, we only expose a named export and so there's no issue with just pointing Node.js to the CommonJS version (we cannot use the module version forimportfrom Node.js to avoid double package hazard). The factory entry points are also not meant for the Web browser which always has a properwindow- and they'd be unfit for an inclusion in a regular script tag anyway. Because of that, we also don't generate minified versions of these entry points.The factory files are not pushed to the CDN since they are mostly aimed at Node.js.
Checklist