v0.1.9

New: imports of non-TS files are checked, with a nonTsFiles access-level option

Imports that resolve to an internal file ImportLint cannot parse as a TS/JS module — CSS modules, JSON, SVG, and so on — are now checked by the package-access rule instead of being silently skipped as unresolved (#6). When tsc-style resolution fails and the specifier itself names a non-TS extension (./Button.module.css), the resolver retries with the plain bundler-style algorithm and accepts the result only if it lands on a non-TS file. TS/JS semantics are untouched: a styles.d.css.ts declaration still wins over the raw .css beside it, and — like tsc — an extensionless specifier never resolves to a non-TS file. As a side effect, the old "unrecognized file extension, skipping" stderr noise for these imports is gone, and import-lint graph lists the non-TS files it found.

A non-TS file has no JSDoc tags, so its exports get the config's defaultImportability, exactly like an untagged TS export — unless the new nonTsFiles option assigns them a level explicitly:

"rules": {
  "package-access": {
    "defaultImportability": "package",
    "nonTsFiles": {
      "**/*.module.css": { "default": "package", "*": "package" }
    }
  }
}

Keys are globs matched against the exporting file's resolved project-relative path (not the import specifier); values map an export name to "public" | "package" | "private". "*" covers every export except default, following the ES spec's export * convention, so default must be assigned by name. Entries are tried in written order and the first match for the imported name wins — put specific patterns first. See the new Non-TS files section in the concepts guide for the full semantics — also covered by the built-in import-lint docs concepts / import-lint docs config.

Note for existing users: this can surface new errors. Under defaultImportability: "package", a cross-package CSS-module or JSON import that was previously skipped now errors. If you want the old don't-check behavior (which is also what eslint-plugin-import-access does — this is now the second deliberate divergence documented in the README's migration section), add:

"nonTsFiles": { "**": { "default": "public", "*": "public" } }

Lint behavior is unchanged for imports that resolved before — TS/JS checking and output are identical to v0.1.8, and the resolver's hot paths are unaffected (the fallback only runs when tsc-style resolution fails on a specifier naming a non-TS extension).

Full Changelog: v0.1.8...v0.1.9