[WIP] Draft PR for adding imports to package.json

[siddarthkay]

This is a WIP PR to just collect my thoughts and to ask questions about this implementation.
fixes #978

Summary

• Add optional imports type to packageJson
• Implement PACKAGE_IMPORTS_RESOLVE inside packages/metro-resolver/src/PackageImportsResolve.js as per spec at https://nodejs.org/api/esm.html#resolver-algorithm-specification
• Do we need to Implement the methods PACKAGE_IMPORTS_RESOLVE depends on like ?:
• lookupParentScope
• readPackageJSON
• packageImportsExportsResolver
• packageTargetResolve
• isValidURL
• packageResolve
• isBuiltinModule
• PackageSelfResolve
• PackageExportsResolve
• update metro resolver to handle imports and to call logic at packages/metro-resolver/src/PackageImportsResolve.js

Test plan

tests must pass by running npm test

[huntie]

Please update this function to use the existing ResolutionContext object, which provides APIs such as context.getPackageForModule() and context.doesFileExist().

• This should enable your implementation to work without importing and using fs.
• Removes the need for separate lookupParentScope and readPackageJSON utils.
• Enables this function to read config options such as resolver.unstable_conditionNames.

The function should also be named to reflect returning a singular Target (typo). Together, the signature might look closer to:

export function resolvePackageTargetFromImports(
  context: ResolutionContext,
  importSpecifier: string,
  importsField: ExportMap,
  platform: string | null,
): FileResolution {

This also means we should move the specifier.startsWith('#') check externally, to around resolve.js#L52 and call this function with the parsed imports field if it exists.

[huntie]

This should be replaced with a dedicated error type — this existed previously and can be copied over: https://github.com/facebook/metro/blob/47856447a885d695f781694e5200ca2c3adecc87/packages/metro-resolver/src/errors/InvalidModuleSpecifierError.js

Similarly for any other errors we're introducing from the Node.js spec.

[huntie]

Do we need to Implement the methods PACKAGE_IMPORTS_RESOLVE depends on[?]

We don't! 😄 packageTargetResolve and PackageExportsResolve are already implemented elsewhere in metro-resolver — please remove.

While this lines up 1:1 with the Node.js resolution algorithm, let's reuse what's available in the rest of the resolver code rather than reimplementing here — which (while not an exact match with Node's strategy) will respect other Metro resolution behaviours such as resolver.extraNodeModules.

Please look to locate the function call for resolvePackageTargetsFromImports() within the main resolve() function and use resolve() to evaluate the package target read from "imports" (updating context.originModulePath when calling this).

The control flow would look roughly like:

• Within resolve()
  • if the import specifier (moduleName) begins with # AND if imports is in context.getPackageForModule(context.originModulePath)
    • get the result of resolvePackageTargetFromImports(context, moduleName, importsField, ...)
    • if a target was returned (containing the matched import specifier value from "imports"), call and return resolve(target)
    • else, fall through (will error after all other resolution steps)

[siddarthkay]

@huntie : Thanks for taking the time to do a detailed PR review! I'll address the feedback 🙏🏻

[siddarthkay]

Resuming work on this.

[kraenhansen]

@siddarthkay do you have plans to continuing working on this?

Alternatively, I'd be interested in taking over the assignment of the original issue.

[siddarthkay]

HI @kraenhansen : hmm, I'd be happy if you took it over. Thank you.

[siddarthkay]

cc @huntie