Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: package.json "imports" field #978

Open
huntie opened this issue May 10, 2023 · 3 comments 路 May be fixed by #995
Open

Feature: package.json "imports" field #978

huntie opened this issue May 10, 2023 · 3 comments 路 May be fixed by #995
Assignees
Labels
馃憢馃徎 Good First Issue An issue or task that is ideal for new open source contributors. Type: Feature Request

Comments

@huntie
Copy link
Member

huntie commented May 10, 2023

馃憢馃徎 Good First Issue

  • An issue or task that is ideal for new open source contributors.
  • Please reach out to the issue creator before claiming an issue to discuss design.

Description

Similar to the "exports" field, the package.json "imports" field is a mapping of private import specifiers (from any modules in that package) to a given target.

Unlike "exports", a target in this case can be either a subpath to a file contained within a package, OR a bare import specifier 鈥斅爐herefore we can treat this value as a new import specifier to resolve() relative to the package path.

// package.json
{
  "imports": {
    "#dep": {
      "node": "dep-node-native",
      "default": "./dep-polyfill.js"
    }
  }
} 

Rough design

This is a significant new feature(!), but is well-described by the spec and relatively isolated. If picking up this task, @huntie and a backup Metro team member will be available to support via DM throughout the time spent on this feature.

Most of the implementation for "imports" should live inside metro-resolver.

  • Add a new experimental config option, resolver.unstable_enablePackageImports. Update: Ideally we can skip this, and add as one PR with decent test coverage.
  • Update the PackageJson type to accept an optional imports property. This should be of type ExportMap.
  • Update the resolver to handle import specifiers beginning with #. This should call new logic in a PackageImportsResolve.js module (that follows the PACKAGE_IMPORTS_RESOLVE function in the Node Resolution Algorithm).
    • The result of this function should return the target import specifier, or a PackageImportNotDefinedError.
    • The calling context in resolve.js should then return the result of resolve(target).

Notes:

  • Conditional "imports" should be handleable with the existing config options and reduceExportMap() function.
  • Tests should be added for all functionality (package-exports-test.js can be copied as a starting point).
@huntie huntie added Type: Feature Request 馃憢馃徎 Good First Issue An issue or task that is ideal for new open source contributors. labels May 10, 2023
@siddarthkay
Copy link

Hello @huntie
I would love to work on adding this feature when you add some more description on the requirement and expectations :)

@huntie
Copy link
Member Author

huntie commented Jun 2, 2023

Hey @siddarthkay! I've added a description now. If you're still happy to take this on, let me know :) (and feel free to DM me on Twitter).

@siddarthkay
Copy link

@huntie : thanks for the detailed description, for now its good enough to get me started! for more questions I'll paste comments here!
Could you please assign this issue to me?

@siddarthkay siddarthkay linked a pull request Jun 5, 2023 that will close this issue
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
馃憢馃徎 Good First Issue An issue or task that is ideal for new open source contributors. Type: Feature Request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants