New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--moduleResolution bundler
(formerly known as hybrid
)
#51669
--moduleResolution bundler
(formerly known as hybrid
)
#51669
Conversation
Summary: X-link: facebook/metro#955 Pull Request resolved: facebook#36584 Changelog: [General][Changed] - Default condition set for experimental Package Exports is now `['require', 'react-native']` The [Exports RFC](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0534-metro-package-exports-support.md) had assumed that supporting the `"import"` condition was a syntax-only difference, given we are not in a Node.js environment — and so was worthwhile to support for maximal ecosystem compatibility. {F915841105} This assumption is similar to [`--moduleResolution bundler` in TypeScript 5.0](microsoft/TypeScript#51669): > bundlers and runtimes that include a range of Node-like resolution features and ESM syntax, but do not enforce the strict resolution rules that accompany ES modules in Node or in the browser > -- microsoft/TypeScript#51669 (comment) However, robhogan has rightly pointed out that **we should not do this!** - ESM (once transpiled) is **not** simply a stricter subset of in-scope features supported by CJS. For example, it supports top-level async, which would be breaking at runtime. - We recently made the same change for our Jest environment: - facebook@681d7f8 As such, we are erring on the side of correctness and supporting only `['require', 'react-native']` in our defaults. At runtime, all code run by React Native is anticipated to be CommonJS. `"exports"` will instead allow React Native to correctly select the CommonJS versions of modules from all npm packages. Metro changelog: [Experimental] Package Exports `unstable_conditionNames` now defaults to `['require']` Reviewed By: robhogan Differential Revision: D44303559 fbshipit-source-id: 0077e547e7775e53d1e4e9c3a9d01347f4fb7d4a
This is a new resolution algorithm in TypeScript that closely matches the one present in popular bundlers like Vite and Webpack. More details: https://devblogs.microsoft.com/typescript/announcing-typescript-5-0-beta/#moduleresolution-bundler microsoft/TypeScript#51669
@andrewbranch why does I've been trying to make a package with conditional exports that use And |
It doesn’t; #52940 removed it. I’ll update the PR description since docs still aren’t on the website (😬) |
Okay great! Thanks for letting me know |
@jedwards1211 No problem. I assume you’re aware that Webpack, and I assume other bundlers too, do apply the |
@andrewbranch so I've learned recently...and even Deno does, somewhat surprisingly |
I found this setting fixed a long running problem I had (yay!). In trying to learn more about it I checked out https://www.typescriptlang.org/tsconfig#moduleResolution , https://www.typescriptlang.org/docs/handbook/modules.html , and https://www.typescriptlang.org/docs/handbook/module-resolution.html and none of them cover it. What's the best reference for details (this PR discussion is rather long)? Hopefully the docs will be updated soon. Thanks! |
The release notes for TypeScript 5.0 recommend using "bundler" when using tools like Vite, esbuild, Webpack, and so on. - Docs (which unfortunately don't say much): https://www.typescriptlang.org/tsconfig#moduleResolution - See also this PR: microsoft/TypeScript#51669
This PR introduces a new
moduleResolution
setting value calledhybrid
bundler
(see #51714), designed primarily for bundlers and runtimes that include a range of Node-like resolution features and ESM syntax, but do not enforce the strict resolution rules that accompany ES modules in Node or in the browser. Special consideration has also been given for bundlers and runtimes that understand TypeScript natively and do not require compilation to JavaScript bytsc
before consumption. Additionally, resolution of package.jsonexports
andimports
can be enabled/disabled/customized in configuration options. This should allow users of different bundlers and runtimes with slight variations in resolution features to customize TypeScript’s resolution settings underbundler
as appropriate.--moduleResolution hybrid
andrewbranch/TypeScript#2 for a diff between those two branchesexports
outside of Node #50794moduleResolution
setting be called? #51714Who should use this mode?
tsc
that will run in Node or the browser without further bundling or processingtsc
that will run in Deno without further bundling or processingComparison with existing module resolution settings
node_modules
packages*.ts
importsexports
exports
conditionsnode
,types
;import
from ESM,require
from CJS;custom additions
types
,import
;custom additions
Module syntax restrictions
--moduleResolution bundler
does not support resolution ofrequire
calls. In TypeScript files, this means theimport mod = require("foo")
syntax is forbidden; in JavaScript files,require
calls are not errors but only ever return the typeany
(or whatever an ambient declaration of a globalrequire
function is declared to return).New compiler options
allowImportingTsExtensions
: Allow imports to include TypeScript file extensions. Requires '--moduleResolution bundler' and either '--noEmit' or '--emitDeclarationOnly' to be set.resolvePackageJsonExports
: Use the package.json 'exports' field when resolving package imports. Enabled by default innode16
,nodenext
, andbundler
.resolvePackageJsonImports
: Use the package.json 'imports' field when resolving imports. Enabled by default innode16
,nodenext
, andbundler
.customConditions
: Conditions to set in addition to the resolver-specific defaults when resolving imports. Valid innode16
,nodenext
, andbundler
.Open questions
resolvePackageJsonExports
andresolvePackageJsonImports
be disableable innode16
andnodenext
? I see no valid reason to disable them in those modes, but I haven’t yet prohibited it.*.ts
imports to resolve in every module resolution mode, or at leastnode16
andnodenext
, to improve consistency and (importantly) portability of .d.ts files between modes. I think @weswigham has already done this in another open PR, so perhaps it won’t be too controversial.bundler
become the new default resolution mode for--module commonjs
? I would like to renamenode
tonode10
in a follow-up PR, and stop maintaining it going forward. It is not a good choice for anyone since Node 10 is long out of service.