New resolver implementation in Rust

[devongovett]

This is a new implementation of Parcel's resolver. It includes a few new features to improve compatibility with other tools:

• package.json exports and imports (Fixes Use package.json#exports map #4155, Fixes Import specifiers starting with a hash # resolve to the current asset #8839)
• tsconfig.json baseUrl, paths, and moduleSuffixes (Fixes [TypeScript] baseUrl inside tsconfig.json not supporting. #202, fixes Implement TypeScript resolver plugin #4936)

It also replaces 3 separate node resolver implementations with a single one. Previously, we had separate implementations for the default resolver plugin vs in the NodePackageManager. Now they all use a single library, written in Rust, which provides lots of feature flags to enable turning on or off different resolver features. This allows us to match Node's behavior when needed, and optionally turn on additional features to match TypeScript, webpack, previous Parcel versions, etc. It will also enable future features like ESM plugins, and prepare us for the future when more of Parcel core is written in Rust.

Since it is written in Rust, most file system operations can happen natively if you are using a NodeFS (and Yarn PnP is not enabled). Otherwise, we pass in JS callbacks that are called to read files. The API in the @parcel/node-resolver-core package is now a wrapper around the Rust implementation providing the same API as before (as long as you weren't using internal methods). Yarn PnP, diagnostics, and some other things like checking dependency versions and resolving builtin polyfills are still done in JS since they are rare and not performance critical.

For package.json exports, we try to match the conditions that webpack applies based on Parcel's environment, though not all of them are supported. Currently, there is no way to specify custom conditions - not sure how we would want to do that.

There are a few questions about how some of these resolution features should work together. For example, should aliases apply to package.json exports or tsconfig paths? Would they go before or after? etc. See some comments in the code for more.

To do

• Clean up code
• Performance testing
• Run a lot more test to ensure compatibility with other tools

[mischnic]

as_bytes()[0] == b'?' is probably incorrect with multibyte characters? It can never be a starting byte in a multibyte utf8 character...

[mischnic]

This could be a breaking change for some plugins. Should we try to keep supporting this? Or was the plan to do a major bump on node-resolver-core anyway?

[devongovett]

Yeah it's a bit hard to support custom main fields with the way package.jsons are parsed now (rust discards unknown fields). Extensions could be done but idk if there are any use cases other than replicating the default logic from here. I think the safest thing would be to bump a major anyway because none of the methods other than resolve exist anymore, and someone might have been using them.

[mischnic]

Changing aliases/exports/... could probably influence whether it's external or not?

[mischnic]

That's for both exports and imports, right?

[mischnic]

Still relevant?

[devongovett]

The node docs have a section on this, and it's even got a special PACKAGE_SELF_RESOLVE function in the spec. But I don't really understand why it's called out specifically, because self references work even without this special handling just by searching the node_modules folders as with any other package. I added some tests for it but 🤷

[mischnic]

Should it also read from jsconfig.json?

parcel/packages/transformers/js/src/JSTransformer.js

Lines 184 to 187 in 9d1933b

	let tsconfig = await config.getConfigFrom<TSConfig>(
	options.projectRoot + '/index',
	['tsconfig.json', 'jsconfig.json'],
	);

[devongovett]

Should it also read from jsconfig.json?

Yeah maybe but it would add yet another file that needs to be checked for in every directory. Also other tools like esbuild don't check for it either. I want to start with supporting tsconfig.json and see if we get feedback about needing jsconfig.json too.

[fregante]

TypeScript and exports? 😱 🎉

[jboler]

Will this new resolver support import path aliases starting with @ ? e.g.

  // package.json
  "alias": {
    "@/**": "/src/$1"
  },

  // component.tsx
  import { thing } from '@/components/...'

[fregante]

Doesn't it already? I think you just need "@/**/*": "./src/$1/$2"

[jboler]

@fregante You're absolutely right - thanks for that!

[nastynaz]

Does this actually work? I've been stuck for 4 hours trying to get it working. I'm on parcel 2.9.0. Fresh repo with the following tsconfig:

{
  "compilerOptions": {
    "target": "es2022",
    "paths": {
      "shared/*": ["./src/shared/*"]
    },
    "include": ["src/**/*"]
  }
}

After running parcel build and then running the code with node, I get a "cannot find package 'shared'" error. The code doesn't exist but the imports are still trying to import a nonexistant 'shared' folder.

I've also tried adding various aliases to my package.json to no avail. If anyone could help me I'd greatly appreciate it!

[fregante]

I think it’s opt-in at the moment. You need to customize it in your parcelrc file:

https://parceljs.org/blog/v2-9-0/#new-resolver

[nastynaz]

@fregante Unfortunately that doesn't work.

@devongovett Since Parcel uses swc under the hood, is it possible to just change the .swcrc file/config it uses?

Because of this issue I went back to using swc. It's pretty easy to set up there, you just copy your tsconfig.json paths statement directly into the .swcrc:

{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "decorators": true
    },
    "target": "esnext",
    "paths": {
      "opensea/*": ["./src/shared/opensea/*"]
    }
  },
  "module": {
    "type": "commonjs"
  },
  "sourceMaps": true
}