broken nested and relative symlinks

[NicholasLYang]

So uhh, this is a bit of a cart and a horse situation. You can extend a tsconfig using a package, e.g.

{
  "extends": "my-package/tsconfig.json"
}

This doesn't seem to work with oxc_resolver, understandably so, since resolving this package import requires...a resolver, which is what we're creating in the first place. But maybe we can do a "best shot" where we use a basic resolver to resolve the extends key?

Thanks!

[Boshen]

Can you get me a production?

I tried adding a test in the branch https://github.com/oxc-project/oxc-resolver/tree/extend-package

just example /Users/boshen/oxc/oxc-resolver/fixtures/tsconfig/cases/extends-package-tsconfig foo

gives me the tsconfig

[src/lib.rs:1116:9] &tsconfig = TsConfig {
    root: true,
    path: "/Users/boshen/oxc/oxc-resolver/fixtures/tsconfig/cases/extends-package-tsconfig/tsconfig.json",
    extends: Some(
        Single(
            "tsconfig-index/tsconfig.json",
        ),
    ),
    compiler_options: CompilerOptions {
        base_url: None,
        paths: Some(
            {
                "foo": [
                    "foo.js",
                ],
            },
        ),
        paths_base: "/Users/boshen/oxc/oxc-resolver/fixtures/tsconfig/node_modules/tsconfig-index",
    },
    references: [],
}

which seems to be correct because paths_base is pointing to tsconfig-index (the "extends": "tsconfig-index/tsconfig.json").

[Boshen]

If you want to debug yourself:

oxc-resolver/src/lib.rs

Line 1140 in 376e254

vec![self.get_extended_tsconfig_path(&directory, tsconfig, s)?]

Resolving extended ts config just reuses the resolver:

oxc-resolver/src/lib.rs

Lines 1193 to 1219 in 376e254

	fn get_extended_tsconfig_path(
	&self,
	directory: &CachedPath,
	tsconfig: &TsConfig,
	specifier: &str,
	) -> Result<PathBuf, ResolveError> {
	match specifier.as_bytes().first() {
	None => Err(ResolveError::Specifier(SpecifierError::Empty(specifier.to_string()))),
	Some(b'/') => Ok(PathBuf::from(specifier)),
	Some(b'.') => Ok(tsconfig.directory().normalize_with(specifier)),
	_ => self
	.clone_with_options(ResolveOptions {
	description_files: vec![],
	extensions: vec![".json".into()],
	main_files: vec!["tsconfig.json".into()],
	..ResolveOptions::default()
	})
	.load_package_self_or_node_modules(directory, specifier, &mut Ctx::default())
	.map(|p| p.to_path_buf())
	.map_err(|err| match err {
	ResolveError::NotFound(_) => {
	ResolveError::TsconfigNotFound(PathBuf::from(specifier))
	}
	_ => err,
	}),
	}
	}

[NicholasLYang]

Thanks for the response! I tracked it down. Seems like this call to realpath here is the culprit. It bubbles up an error which short circuits the logic in load_node_modules that's testing the different modules options.

[NicholasLYang]

Would the solution be to recover in this call failing like the fs.read_to_string call above it? Happy to open a PR if that's the case

[Boshen]

Happy to open a PR if that's the case

A reproduction would be better for me 😅

[NicholasLYang]

I'm still working on a repro, but it appears that the issue is in fact inside realpath. Specifically, the canonicalization code is attempting to resolve a relative symlink, but that symlink is nested inside another directory that is symlinked. Concretely, this line here is incorrect because that path may not be fully canonicalized.

[NicholasLYang]

Here's your repro: https://github.com/NicholasLYang/oxc-repro. Let me know if you have any questions!

[Boshen]

@NicholasLYang released in v2.0.0