need to revert #80, see https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-0.html#supporting-multiple-configuration-files-in-extends

This was buried so deep in the docs that I couldn't find it until someone brought it up.

          It would be nice to add a message in the assertion that explains the assertion itself. At the moment there isn't much context

Originally posted by @ematipico in #92 (comment)

Example:

{
  "browser": {
    "./e.js": "./e.js",
    "f.js": "./f.js"
  }
}

webpack works well with these alias pairs.

Related: web-infra-dev/rspack#5039

Code coverage is at 95%, but some branches are still missing a test case. There are also TODOs in many places 😞

https://github.com/microsoft/TypeScript/pull/58042

(as mentioned on discord) I've been working on migrating a project from some custom resolution logic to oxc-resolver. Here's some feedback about my experience so far:

path argument

There are no docs describing the public API of the crate - the page for the resolver just has a link to an example as the only documentation. The example includes a comment which says Path to directory, must be in absolute path.

The crate docs just say: Resolve specifier at an absolute path with no mention of the requirement that it be a folder.

I misread this in example and made the assumption that I was passing the "target" file path (the file that "owns" the dependencies) to the resolve function. This caused many resolutions to fail because the code assumes the path is a folder and does path.join(relative).

Suggestions:

• Improve docs for the API
• Add an error if the path passed to .resolve is a file instead of a folder
  • Alternately - take the .parent().unwrap() of a file automatically

extensions option

I had all my extensions configured without a leading .. This caused all my extensionless resolutions to fail because the code assumes the extension starts with a . and does concatenate(path, extension).

The docs allude to this expectation by showing the defaults as having a leading . but it does not state the requirement.

Suggestions:

• Describe the assumptions in the docs
• Add an error if any of the extensions passed to the config does not start with a .
  • Alternately - normalise the extensions to start with a .

Hi there, I know the oxc-resolver npm package is still in development, but I was trying it out on a POC I was working on and wanted to report this issue.

"Error: Package subpath '.' is not defined by "exports" in [path]/node_modules/css-tree/package.json"

I actually see the error for a few packages, and all of those packages seem to have their exports correctly defined.

Looking at css-tree for example:
https://github.com/csstree/csstree/blob/ba6dfd8bb0e33055c05f13803d04825d98dd2d8d/package.json#L23-L27

The resolver is set up like this:

  const resolver = new ResolverFactory({
    extensions: ['.ts', '.tsx', '.js', '.jsx', '.mjs', '.cjs'],
    mainFields: ['module', 'main'],
  });

Perhaps unrelated, I'm also getting Error: Cannot find module 'fs' for built in modules. We use the node: protocol for built-ins in case that helps there.

https://www.typescriptlang.org/tsconfig#extends

The current napi version needs to pass all the options in

https://github.com/oxc-project/oxc_resolver/blob/009927b65d793958521304e9e238328e15146c8f/napi/src/lib.rs#L53

Note: enhanced-resolve accepts a path-to-object behavior for some of the options, e.g.

https://github.com/oxc-project/oxc_resolver/blob/009927b65d793958521304e9e238328e15146c8f/src/options.rs#L48-L52

The napi binding will be a bit more involved for these cases :-(

This hot path is slow

Need to continue the work on #134, all other fields need to be dynamically retrieved instead of cached.

The horror of dynamic values 😡

I am interested in integrating oxc_resolver into my existing Webpack setup.

Webpack uses echanced-resolver internally for resolution. How do I bring in oxc_resolver in the existing flow? An example repo would go a long way.

Related code:

The current behavior of oxc-resolver is correct based on the spec, but not flexable.

"default" - the generic fallback that always matches. Can be a CommonJS or ES module file. This condition should always come last. link

Though spec said the "default" should always come last, but nodejs actually doesn't do strong validation on it. If "default` shows , it will be matched once detecting it.

Context:

• Esbuild follows the actual behavior of nodejs rather the spec.
• • Test: https://github.com/evanw/esbuild/blob/83e8c7f0b86e7b627990339870c8cc68c154c77b/internal/bundler_tests/bundler_packagejson_test.go#L1566-L1597
• • Test Output: https://github.com/evanw/esbuild/blob/83e8c7f0b86e7b627990339870c8cc68c154c77b/internal/bundler_tests/snapshots/snapshots_packagejson.txt#L575-L578

Related:

• webpack/enhanced-resolve#421
• evanw/esbuild@8b16b2d

master

i'm dev rolldown for esbuild package_json test cases

when i migrate TestPackageJsonBrowserIssue2002B

https://github.com/evanw/esbuild/blob/main/internal/bundler_tests/bundler_packagejson_test.go#L830

i found some resovle error in oxc-resolver

please help me check

In order to quickly reproduce the bug I've created a git repo of code that can be reproduced.

https://github.com/zhusjfaker/oxc-resolver-has-issue-in-esbuild-test-case-packagejson-2002b/blob/master/tests/mod.rs#L44

https://github.com/zhusjfaker/oxc-resolver-has-issue-in-esbuild-test-case-packagejson-2002b

web-infra-dev/rspack#5579

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Location: .github/renovate.json
Error type: The renovate configuration file contains some invalid settings
Message: Invalid schedule: Invalid schedule: Failed to parse "before 8am on on monday"

There's still a lot of TODO's let over for error handling

https://github.com/oxc-project/oxc_resolver/blob/009927b65d793958521304e9e238328e15146c8f/src/error.rs#L55-L79

https://yarnpkg.com/features/pnp

Please +1 and link your public repository if you're using yarn pnp.

In postcss, oxc-resolver fails to return path = ignore

https://github.com/postcss/postcss/blob/763d57b78a57b7abb6aaf745ab046ad9380cca9c/package.json#L138-L144

  "browser": {
    "./lib/terminal-highlight": false,
    "source-map-js": false,
    "path": false,
    "url": false,
    "fs": false
  },

This project version is: [email protected] as writing of this issue, but on npm version is [email protected]

• https://github.com/web-infra-dev/rspack/issues/4446

Need to expose all options as a napi object in napi/resolver

https://github.com/webpack/enhanced-resolve/blob/58464fc7cb56673c9aa849e68e6300239601e615/types.d.ts#L486-L630

Hi oxc project team

Thank you for very fast and useful tool/project. I am tested oxc_resolver and it's ~2-3x faster, not ~28x.
Source is here

It seems like we can publish 1.0 after all the issues are resolved.

https://github.com/import-js/eslint-import-resolver-typescript

ref: import-js/eslint-import-resolver-typescript#254

Rspack requires returning of raw serde json for:

• side effects
• rule.descriptionData https://github.com/search?q=repo%3Awebpack%2Fwebpack+descriptionData&type=code

We should feature gate this because regular usage don't require it.

mainFields: ['browser', 'module', 'main']

and also link to webpack resolve doc

https://github.com/webpack/webpack/issues/14166

https://github.com/evanw/esbuild/blob/main/internal/bundler_tests/bundler_packagejson_test.go#L766

├── _config.json
├── dist
│   └── entry.js
└── src
    ├── demo-pkg
    │   ├── ext
    │   ├── ext-browser
    │   ├── no-ext
    │   ├── no-ext-browser
    │   └── package.json
    └── entry.js

in the file system

./src/demo-pka/package.json

{
  "browser": {
    "./no-ext": "./no-ext-browser/index.js",
    "./ext/index.js": "./ext-browser/index.js"
  }
}

./src/demo-pka/entry.js

import { browser as a } from './demo-pkg/no-ext'
import { node as b } from './demo-pkg/no-ext/index.js'
import { browser as c } from './demo-pkg/ext'
import { browser as d } from './demo-pkg/ext/index.js'
console.log(a)
console.log(b)
console.log(c)
console.log(d)

i want resolver 'import { browser as a } from './demo-pkg/no-ext'' --> is './src/demo-pkg/no-ext-browser/index.js' but now
is ->

'./src/demo-pkg/no-ext/index.js'

Am I overlooking a configuration item or is there something wrong with the implementation itself?

In typescript it's possible to import from a module that only has a @types/ definition.
Example -- if you "right click -> peek definition" on the import source you'll see it mentions node_modules/@types/google__maps.

From what I can tell there isn't a way to resolve this import without manually specifying a mapping.
Am I correct in this? Or is there a way to support it?

oxc_resolver: 1.2.0-1.3.0
os: Windows

Summary

let root = dir().join("fixtures\\enhanced_resolve\\test\\fixtures");
let mut ctx = ResolveContext::default();

let resolver = Resolver::new(ResolveOptions {
    alias: vec![(
        "@".into(),
        vec![AliasValue::Path(root.join("alias").to_string_lossy().into())],
    )],
    ..ResolveOptions::default()
});
let _ = resolver.resolve_with_context(root, "@/files/a", &mut ctx);

for d in ctx.file_dependencies.iter() {
    println!("{}", d.to_string_lossy());
}

Expected

C:\Users\imkf\Developer\oxc-resolver\fixtures\enhanced_resolve\test\fixtures\alias\files\a.js seen in output,

Actual

C:\Users\imkf\Developer\oxc-resolver\fixtures\enhanced_resolve\test\fixtures\alias/files/a.js got

Related

web-infra-dev/rspack#5445