jiti 2.7.0

Source: https://github.com/unjs/jiti
Tag scanned: v2.7.0
Compared with: v2.6.1 (1 signals introduced since)
Files: 153 scanned, 6 skipped (binary, oversized, or unrecognised)
Signals: 0 critical · 0 warn · 8 info
Scan time: 7.7 s
LLM review: Reviewed by claude-haiku-5-5 (Anthropic): 7 of 7 warn and critical signals; 7 demoted to info.
Disclude version: 4.1.0
Scanned (UTC): 2026-10-22 17:03

Signals

Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.

info ~~warn~~ → info by review dynamic-import lib/jiti-static.mjs:10:30 new in this release

dynamic `import(...)` with a non-literal specifier (ast pass, confidence 0.65)
```
const nativeImport = (id) => import(id);

export function createJiti(id, opts = {}) {
```
likely benign LLM, confidence 0.92 A one-line wrapper around native dynamic import used by jiti to load modules.
Reasoning
`const nativeImport = (id) => import(id);` is a thin wrapper that lets jiti load modules through the host's native import. The specifier comes from the caller who asked jiti to load a module, and nothing in the snippet is encoded, hidden, or executed from an opaque source. This is normal behavior for a module loader.

info long-line README.md:15:1

line length 945 characters (raw pass, confidence 0.50)

[Docusaurus](https://docusaurus.io/), [ESLint](https://github.com/eslint/eslint), [FormKit](https://formkit.com/), [Histoire](https://histoire.dev/), [Knip](https://knip.dev/), [Nitro](https://nitro.unjs.io/), [Nuxt](https://nuxt.com/), [PostCSS loader](https://github.com/webpack-contrib/postcss-loader), [Rsbuild](http

info ~~warn~~ → info by review dynamic-import lib/jiti-native.mjs:58:24

dynamic `import(...)` with a non-literal specifier (ast pass, confidence 0.65)
```
          }
          return await import(resolved, importAttrs);
        } catch (error) {
          if (error.code === 'ERR_MODULE_NOT_FOUND' || error.code === 'ERR_UNSUPPORTED_DIR_IMPORT') {
```
likely benign LLM, confidence 0.90 A loader's native ESM import of a resolved module path, with fallback handling for Node resolution errors.
Reasoning
The snippet is a retry path in a module loader. It imports a resolved path with import attributes and handles ERR_MODULE_NOT_FOUND and ERR_UNSUPPORTED_DIR_IMPORT, which are standard Node loader errors. Dynamic import of a resolved specifier is the core purpose of a transpile-and-load library like jiti, so this is an expected pattern rather than obfuscation.
info ~~warn~~ → info by review dynamic-import lib/jiti.cjs:8:30

dynamic `import(...)` with a non-literal specifier (ast pass, confidence 0.65)
```
const nativeImport = (id) => import(id);

let _transform;
```
likely benign LLM, confidence 0.92 A CJS build's wrapper around native dynamic import for loading modules at runtime.
Reasoning
The same `nativeImport` wrapper appears in the CJS build of jiti. A dynamic import whose specifier the caller supplies is required for a runtime TypeScript/ESM loader to function. The snippet shows no obfuscation or concealment.
info ~~warn~~ → info by review dynamic-import lib/jiti.mjs:8:30

dynamic `import(...)` with a non-literal specifier (ast pass, confidence 0.65)
```
const nativeImport = (id) => import(id);

let _transform;
```
likely benign LLM, confidence 0.92 An ESM build's wrapper around native dynamic import for loading modules at runtime.
Reasoning
The ESM build has the same `nativeImport` wrapper as the other jiti entry points. Its purpose is to load user modules through the host's native import, which is the library's documented function. The snippet shows nothing suspicious.
info ~~warn~~ → info by review dynamic-import test/fixtures/data-uri/index.ts:6:3

`require` called with a non-literal specifier (ast pass, confidence 0.60)
```
try {
  require(uri);
  throw null;
} catch (error) {
```
likely benign LLM, confidence 0.90 A test fixture that calls require on a data URI and expects it to throw.
Reasoning
This is a test fixture for data-URI handling. `require(uri)` is wrapped in try/catch and followed by `throw null`, so the test checks that the require call fails. The non-literal specifier is the point of the test, and it is not used on any untrusted path in shipped code.
info ~~warn~~ → info by review dynamic-import test/fixtures/data-uri/index.ts:14:7

dynamic `import(...)` with a non-literal specifier (ast pass, confidence 0.65)
```
}
await import(uri);
```
likely benign LLM, confidence 0.90 A test fixture that dynamically imports a data URI to test ESM loading.
Reasoning
This is another data-URI test fixture, where `await import(uri)` exercises ESM loading of a data URI. The dynamic specifier is intentional test input. The fixture is in the test directory and the snippet has no concealment or execution of decoded payloads.
info ~~warn~~ → info by review dynamic-import test/node-register.test.mjs:13:21

dynamic `import(...)` with a non-literal specifier (ast pass, confidence 0.80)
```
  test("fixtures/" + fixture + " (ESM)", async () => {
    const promise = import(`./fixtures/${fixture}`);
    const shouldReject =
      fixture === "error-parse" || fixture === "error-runtime";
```
likely benign LLM, confidence 0.93 A test that dynamically imports local fixture modules by name.
Reasoning
In a test file, the template-literal specifier `./fixtures/${fixture}` loops over known fixture names to test loading. The fixtures are local and enumerated by the test. Nothing is decoded or fetched from outside, so this is a normal test pattern.

Reproduce This Scan

Run disclude locally to verify. Add --format sarif for SARIF output. Add --llm (with an API key in the environment) to include the LLM review.

cargo install disclude --version 4.1.0
git clone https://github.com/unjs/jiti jiti && cd jiti
git checkout v2.7.0
disclude scan --severity info --diff v2.6.1 .