import/no-cycle with TypeScript + ESM

[LukeNotable]

Trying out oxlint for the first time in the hope that it can at least give us a fast check on import/no-cycle. I have a TypeScript project using ESM, thus files like:

// foo.ts
import { Bar } from './bar.js';

// bar.ts
import { Foo } from './foo.js';

However, the rule fails to flag this as a problem. But if I remove the .js extension, the rule behaves correctly. However, the .js extension is required under ESM.

I recall a similar issue with the original eslint-plugin-import, which required eslint-import-resolver-typescript, and I see there's an oxc-resolver, so I wonder if I just need to do some additional configuration to use it.

[Boshen]

Are there any tsconfig.json configurations that could tell me this extension usage?

The current resolver does not have extensionAlias set.

oxc/crates/oxc_linter/src/service/runtime.rs

Lines 53 to 68 in 6e68c93

	fn get_resolver(tsconfig: Option<PathBuf>) -> Resolver {
	use oxc_resolver::{ResolveOptions, TsconfigOptions, TsconfigReferences};
	let tsconfig = tsconfig.and_then(|path| {
	if path.is_file() {
	Some(TsconfigOptions { config_file: path, references: TsconfigReferences::Auto })
	} else {
	None
	}
	});
	Resolver::new(ResolveOptions {
	extensions: VALID_EXTENSIONS.iter().map(|ext| format!(".{ext}")).collect(),
	condition_names: vec!["module".into(), "require".into()],
	tsconfig,
	..ResolveOptions::default()
	})

I don't really want to add a resolver configuration to oxlintrc 😅

[LukeNotable]

Are there any tsconfig.json configurations that could tell me this extension usage?

The pertinent part would just be:

  "compilerOptions": {
    "module": "nodenext",
    "moduleResolution": "nodenext",
  },

I don't really want to add a resolver configuration to oxlintrc 😅

Right, ideally the built-in resolver would just do the right thing for TypeScript.