Summary

Add support for rslint.config.{ts|mts|js|mjs} using ESLint flat config style. rslint.json/jsonc remains backward-compatible but deprecated.

Usage

Quick start

# Generate a default JS config in the current directory
npx rslint --init

This creates a config file with a recommended preset. The file extension depends on the project setup (following the ESLint convention):

• Has tsconfig.json → rslint.config.ts
• Has "type": "module" in package.json → rslint.config.js (ESM syntax)
• Otherwise → rslint.config.mjs (ESM syntax, .mjs ensures Node treats it as ESM)

// rslint.config.mjs
import { defineConfig, ts } from '@rslint/core';

export default defineConfig([
  // Global ignores — entry with only `ignores` excludes matching files from all rules
  // (same semantics as ESLint flat config)
  { ignores: ['dist/**', 'build/**', 'coverage/**', 'node_modules/**'] },

  // Use the recommended preset for TypeScript projects
  // Includes @typescript-eslint/recommended + eslint:recommended overrides
  ts.configs.recommended,

  // Per-project rule overrides
  {
    rules: {
      '@typescript-eslint/no-explicit-any': 'off',
    },
  },
]);

Available presets

Each preset lists all official rules — implemented ones are active, unimplemented ones are commented out for visibility.

Config file priority

rslint.config.js > .mjs > .ts > .mts > rslint.json > rslint.jsonc

Use --config <path> to specify a custom config file path.

TypeScript config files

.ts/.mts config files are supported via:

1. Native import() on Node.js ≥ 22.6 (detected via process.features.typescript)
2. jiti fallback (install as dev dependency: npm install -D jiti)

Architecture

JS handles config loading, Go handles rule execution — both share identical rule resolution logic.

• JS side loads config file → serializes to JSON → pipes to Go via --config-stdin
• stdout/stderr inherited — Go outputs directly to terminal, no IPC changes
• JSON config: normalizeJSONConfig injects core/plugin rules at load time, so GetConfigForFile processes both config types identically

Config merging (ESLint flat config semantics)

• rules / settings: shallow merge, later entries override
• languageOptions: deep merge (parserOptions fields merged independently; ProjectService uses *bool to distinguish unset from explicit false)
• Entry with only ignores acts as a global ignore
• No matching entry → file is not linted (GetConfigForFile returns nil)

Monorepo per-file config resolution (LSP)

VS Code extension discovers all rslint.config.{js,mjs,ts,mts} files in the workspace via workspace.findFiles and sends the full set to the LSP server via rslint/configUpdate notification. Config files are loaded in parallel via Promise.allSettled — a broken config in one sub-package does not prevent other configs from loading. Config keys use URI strings (file:///...) throughout, matching LSP protocol convention — this eliminates cross-platform path separator issues by design. The rslint/configUpdate handler is registered as a blocking method to ensure config updates are serialized on the dispatch loop, preventing data races with concurrent diagnostics.

When linting a file, getConfigForURI walks up the URI hierarchy from the file's directory to find the nearest JS/TS config (ESLint v10 flat config behavior), returning both the config entries and the config's own directory as cwd for glob matching. This ensures monorepo sub-package patterns like files: ['src/**/*.ts'] resolve relative to the sub-package root, not the workspace root. If no JS config matches, it falls back to the JSON config with s.cwd (workspace root) as cwd.

uriToPath correctly handles Windows drive letter URIs (file:///C:/Users/... → C:/Users/...) to ensure the returned cwd uses a DOS root consistent with os.Getwd(), avoiding root-type mismatches in tspath.ConvertToRelativePath.

The handleConfigUpdate handler distinguishes nil payloads (malformed — preserves existing configs) from explicitly empty configs arrays (legitimate "all configs deleted" — clears state).

CLI error handling

loadConfigFile and normalizeConfig failures are caught independently with user-friendly error messages (e.g., "Error: failed to load config ...", "Error: invalid config ..."), rather than exposing raw stack traces.

Pure JS project support

• When no parserOptions.project is specified, auto-detect tsconfig.json in cwd
• If no tsconfig found, generate a temporary one with allowJs: true for JS-only projects
• LSP accepts JSON configs without parserOptions.project (session discovers tsconfig files independently via projectService)

Config export structure

Config presets are exported as named exports from the main entry point:

import { ts, js, reactPlugin, importPlugin } from '@rslint/core';
// ts.configs.recommended, js.configs.recommended, reactPlugin.configs.recommended, importPlugin.configs.recommended

TS config loading strategy

• Prefer native import() (Node 22.6+, detected via process.features.typescript), fall back to jiti (optional peer dep)
• jiti is initialized with path.dirname(configPath) as base to ensure relative imports in config files resolve correctly

Scope of Changes

• Go: --config-stdin flag with 50MB size guard, unified GetConfigForFile(filePath, cwd) merge logic with explicit config directory, normalizeJSONConfig for JSON default rules, --init generates .js/.mjs based on package.json "type" field (ESLint convention), deprecation warning for JSON config, pure JS project tsconfig fallback, isFileMatched/isFileIgnored take cwd parameter, RegisterAllRules wrapped with sync.Once to fix concurrent map writes, textDocument/codeAction added to blocking methods to prevent data race on s.diagnostics
• JS: cli.ts (config discovery + node:util parseArgs with --config=value and -- separator support + stdin pipe + user-friendly error handling for config load/validation failures), config-loader.ts (load/normalize with files/ignores type validation, jiti uses config file directory as base), define-config.ts, preset configs (ts.configs.recommended, js.configs.recommended, reactPlugin.configs.recommended, importPlugin.configs.recommended) aligned with official eslint/typescript-eslint presets (added missing no-with off in TS overrides, commented unimplemented rules: no-new-symbol, no-unassigned-vars, preserve-caught-error)
• LSP: handleConfigUpdate notification handler with multi-config support (URI-keyed jsConfigs map), registered as blocking method for concurrency safety, nil vs empty payload guard, getConfigForURI returns (config, cwd) tuple — walks URI hierarchy for nearest config and returns per-config directory as cwd for correct glob matching, uriToPath handles Windows drive letter URIs (file:///C:/... → C:/...), uriDirname helper for platform-independent URI manipulation, reloadConfig no longer validates tsConfigs (session handles discovery), clears JSON config path to prevent watcher override
• VSCode: loadAndSendConfig discovers all JS configs via workspace.findFiles, loads in parallel via Promise.allSettled (one broken config doesn't block others), sends as URI-keyed array, ESM cache busting for hot reload (.js/.mjs directly, .ts/.mts with native import fallback to jiti), configWatcher for **/rslint.config.{ts,mts,js,mjs}
• Tests:
  • Go unit: config merge logic (30+ tests), handleConfigUpdate including malformed/nil payload tests, getConfigForURI with monorepo multi-package (4 packages), 3-level nesting, Windows URI + cwd assertion, uriToPath cross-platform (Unix/Windows drive letter/UNC/edge cases), uriDirname edge cases, isFileIgnored/isFileMatched with cwd parameter, GetConfigForFile cwd-based matching and ignores including Windows paths (forward-slash cwd, backslash cwd, monorepo sub-package), --init with type:module/.mjs/.ts variants, reloadConfig accepts config without tsconfigs, isBlockingMethod unit test (including codeAction) + dispatch loop serialization test for rslint/configUpdate, RegisterAllRules concurrent safety test with -race
  • JS unit: normalizeConfig validation, loadConfigFile with Promise export, defineConfig identity check, config presets importability and structure
  • CLI e2e: JS config auto-detection (.js/.ts), --config flag (equals/space format), flag passthrough (--fix/--quiet/--format), --init generation (.ts/esm .js/non-esm .mjs/no-pkg .mjs), JS-over-JSON priority, global ignores, rules off, src/**/*.ts pattern matching with correct cwd, user-friendly error for syntax errors and non-array configs
  • VS Code e2e: single-project JS config (diagnostics, priority over JSON, hot reload, delete, create), monorepo multi-config (root/foo/bar resolution with src/**/*.ts pattern, sub-package config change, sub-package config deletion fallback, root config change, broken config resilience — valid configs still work alongside broken sibling, broken package falls back to root, corrupted config at runtime doesn't break other configs, dynamic sub-package config creation with fallback on delete, root config deletion isolation — sub-packages with own config unaffected), no-config fallback, full config lifecycle (no config → JSON created → JS override → JS deleted → JSON restored → JSON deleted)

Known Limitations

• LSP cannot load JS/TS config files directly (requires VS Code extension to send resolved config via rslint/configUpdate notification)
• js.configs.recommended for pure JS projects generates a temporary tsconfig; users with complex setups should provide their own

Checklist

• Tests updated
• Documentation updated (or not required)