SonarJS does not correctly resolve Bun’s default catalog when it is defined at the root of package.json.
Originally reported here:
opened 08:19AM - 05 Sep 26 UTC
closed 06:20PM - 05 Sep 26 UTC
A-linter
### What version of Oxlint are you using?
^1.81.0
### What command did you run… ?
`oxlint .`
### What does your `.oxlintrc.json` (or `oxlint.config.ts`) config file look like?
```ts
import { defineConfig } from "oxlint";
import antiSlop from "ultracite/oxlint/anti-slop";
import core from "ultracite/oxlint/core";
import { jsPluginSettings, selectJsPlugins } from "ultracite/oxlint/js-plugins";
import react from "ultracite/oxlint/react";
import tanstack from "ultracite/oxlint/tanstack";
import tanstackJsPlugins from "ultracite/oxlint/tanstack/js-plugins";
import vitest from "ultracite/oxlint/vitest";
const jsPlugins = selectJsPlugins(["github", "sonarjs", "react-doctor"]);
export default defineConfig({
extends: [
antiSlop,
core,
react,
vitest,
tanstack,
tanstackJsPlugins,
jsPlugins,
],
ignorePatterns: core.ignorePatterns,
jsPlugins: jsPlugins.jsPlugins,
overrides: [
{
// These tests intentionally exercise plain-http URLs: the feature
// under test is which http:// URLs are accepted for local dev.
files: ["apps/mobile/src/__tests__/flows.test.ts"],
rules: { "sonarjs/no-clear-text-protocols": "off" },
},
{
// TanStack file-based routing mandates $ and __ route filename segments.
files: ["apps/web/src/routes/**", "apps/web/src/routeTree.gen.ts"],
rules: { "github/filenames-match-regex": "off" },
},
{
// Expo Router mandates _layout and route filenames.
files: ["apps/mobile/src/app/**"],
rules: { "github/filenames-match-regex": "off" },
},
{
// Metro bundler config must be CommonJS.
files: ["apps/mobile/metro.config.js"],
rules: { "unicorn/prefer-module": "off" },
},
],
settings: jsPluginSettings,
});
```
### What happened?
Bun `1.4.0`. Default catalog defined at **top-level** root `package.json` `"catalog"` (Bun-supported form).
### Minimal package.json
```json
{
"workspaces": ["apps/*", "packages/*", "tooling/*"],
"devDependencies": {
"@types/bun": "catalog:",
"effect": "catalog:",
"hono": "catalog:",
"vitest": "catalog:"
},
"catalog": {
"@types/bun": "1.4.0",
"effect": "4.0.0-rc.112",
"hono": "4.13.7",
"vitest": "5.0.0"
},
"packageManager": "bun@1.4.0"
}
```
`bun install` resolves these correctly.
### What happened?
```text
Dependency "@types/bun" could not be resolved for catalog "default"
Dependency "effect" could not be resolved for catalog "default"
Dependency "hono" could not be resolved for catalog "default"
Dependency "vitest" could not be resolved for catalog "default"
```
Still **0 warnings / 0 errors**, exit **0**.
### Expected
Resolve bare `catalog:` against Bun’s default catalog from root `package.json`:
- top-level `"catalog": { … }` (this case), and/or
- `"workspaces": { "packages": [...], "catalog": { … } }`
Do not emit unresolved-catalog warnings when those entries exist.
### Note
Message uses catalog `"default"` (pnpm naming). Bun’s default catalog is the singular `"catalog"` field, not necessarily `catalogs.default`.
Oxc traced the warning to SonarJS:
for (const [depName, depVersion] of Object.entries(deps)) {
if (typeof depVersion === 'string' && depVersion.startsWith('catalog:')) {
const catalogName = depVersion.slice('catalog:'.length).trim() || 'default';
const resolvedDep =
catalogName === 'default'
? catalogSource?.catalog?.[depName]
: catalogSource?.catalogs?.[catalogName]?.[depName];
resolvedDeps[depName] = resolvedDep ?? depVersion;
!resolvedDep &&
console.debug(
`Dependency "${depName}" could not be resolved for catalog "${catalogName}"`,
);
} else {
resolvedDeps[depName] = depVersion ?? '';
}
}
modifiedPackageJson[field] = resolvedDeps;
}
return modifiedPackageJson;
}
Example:
{
"dependencies": {
"effect": "catalog:"
},
"catalog": {
"effect": "4.0.0-rc.112"
}
}
Bun resolves this correctly, but SonarJS outputs:
Dependency "effect" could not be resolved for catalog "default"
Expected: bare catalog: should resolve against Bun’s top-level "catalog" field without emitting the warning.
andres
September 9, 2026, 9:33am
3
Hey @mynameistito , welcome to the Community!
It seems like the closed PR you linked saw some activity recently when a user commented that we made mistake in assuming this wasn’t supported. It’s quite great timing that you brought this up at the same time as this happened! (was it you who commented in the PR?
We now have another PR to finally address this, so I recommend you follow the progress there.
Hello @mynameistito ,
thanks for the heads up. We are aware and this will be fixed in the coming days.
Cheers!
Too easy legend!
I saw it on git being re implemented tyty!
)