Skip to main content
interlace
Plugin: reliability

Changelog

Release history and version updates for eslint-plugin-reliability

Live from GitHub

This changelog is fetched directly from CHANGELOG.md on GitHub and cached for 2 hours.

Live changelogfrom eslint-plugin-reliability/CHANGELOG.md, cached for 2 hours.Edit on GitHub

[3.1.3] - 2026-05-03

3.1.11

Patch Changes

  • #411 d0cc8b6 Thanks @ofri-peretz! - Ship the JavaScript without tsc's layout.

    Every emitted .js is re-written through esbuild's minifyWhitespace, which removes indentation and line breaks. Across the ecosystem that is 3233 kB -> 2023 kB of shipped JavaScript, a 37% cut; on disk a package install drops about 28%. Indentation alone was ~32% of a compiled rule file.

    This is deliberately NOT minification. Identifiers keep their names, string contents are untouched, and the syntax tree is not rewritten — rule meta (messages, schema, docs URLs) stays byte-identical, which is what the docs site and --print-config read, and a stack trace from inside a rule still names the function it came from. Full mangling would have bought another 4 kB gzipped and cost both.

    Verified against the published artifact: identical lint findings including message IDs, identical rule names, and zero differences across every rule's meta, messages, schema and presets.

  • Updated dependencies [7663cfd, d0cc8b6]:

    • @interlace/eslint-devkit@1.10.0

3.1.10

Patch Changes

  • #381 74bbf60 Thanks @ofri-peretz! - Load rule modules on demand instead of at plugin load.

    Every plugin barrel used to require all of its rules the moment ESLint loaded the plugin, whether or not your config enabled them. plugin.rules[id] is only ever read for rules a config turns on, so the rest was parse-and-compile cost for code that never ran.

    The published entry now exposes each rule behind a getter, so a rule module is read the first time something asks for it. Measured on a 7-plugin config with 34 rules enabled: 163 rule modules loaded and 251 ms of plugin load, against 34 modules and 8.5 ms — total ESLint wall time 251 ms → 109 ms. On a preset that enables most of a plugin (node-security/recommended, 25 of 37) it is a wash, 72 ms → 65 ms. It is never slower; the win scales with how many plugins you stack and how few of their rules you use.

    Nothing about the plugin API changes. Object.keys(plugin.rules) still lists every rule without loading any of them, repeated reads return the same object, and the ./oxlint sub-export is the same plugin object it always was.

    eslint-plugin-jwt and eslint-plugin-vercel-ai-security also re-export their rule objects as named top-level exports, which cannot be deferred — those two keep loading eagerly.

  • #381 74bbf60 Thanks @ofri-peretz! - Declare what we support, load only what we use

    tslib is gone from every package. It was a NON-optional peer of @interlace/eslint-devkit, so all 26 plugins declared it as a dependency to satisfy that peer — 124 kB every consumer installed so twelve require("tslib") calls could resolve. The shipped JavaScript now inlines the TypeScript helpers instead (--importHelpers false on the emit pass that already re-writes it), costing ~9.5 kB in devkit. Zero tslib requires remain anywhere; verified by installing every plugin with no tslib in the tree and loading all 26 with every rule intact.

    eslint-plugin-import-next had a phantom dependency. Its rules require("typescript") at module load, but it was declared in neither dependencies nor peerDependencies — it worked only because something else in the tree happened to install it. A clean install crashed the whole plugin, not just the type-aware rules. typescript is now a required peer, which is what the code actually needs.

    23 "technologies we support" declarations did nothing. Seven plugins listed their target libraries in peerDependenciesMeta with no matching peerDependencies entry, and npm ignores meta for a package that is not declared a peer — verified by installing eslint-plugin-express-security and watching nothing install and nothing warn. eslint-plugin-jwt appeared to support six JWT libraries and formally supported none. All 23 are now real optional peers, matching the convention pg, mongodb, prisma and the other nine already followed:

    plugintechnologies now actually declared
    eslint-plugin-jwtjsonwebtoken, @nestjs/jwt, express-jwt, jose, jwks-rsa, jwt-decode
    eslint-plugin-lambda-security@aws-sdk/client-lambda, @middy/core, @middy/http-cors, @middy/http-security-headers, @middy/validator
    eslint-plugin-express-securityexpress, helmet, cors, csurf, express-rate-limit
    eslint-plugin-nestjs-security@nestjs/common, @nestjs/throttler, class-validator, class-transformer
    eslint-plugin-vercel-ai-securityai
    eslint-plugin-maintainability, eslint-plugin-react-featurestypescript

    All optional, so nothing is installed on the consumer’s behalf — the declaration is the supported-technology signal, which is exactly what it was meant to be.

    A new gate compares declared dependencies against what the emitted JavaScript actually loads, in both directions: a require with no declaration (works until someone installs cleanly) and a declaration nothing requires (weight every consumer pays). It understands that a dependency may exist to satisfy an optional peer of another dependency, which is why eslint-plugin-import-next legitimately declares oxc-resolver that devkit lazily loads.

  • #335 47cde07 Thanks @ofri-peretz! - Fix the ./oxlint subpath export, which pointed at src/oxlint.js — a file no build produces. require('<package>/oxlint') threw MODULE_NOT_FOUND on every published package, while every README documented that exact wiring for oxlint's jsPlugins. The export now points at the build output, dist/src/oxlint.js.

    The path was hardcoded in scripts/generate-oxlint-shims.ts, so the generator rewrote any manual correction back to the broken value on the next drift check — fixed there rather than per package.

    This release also carries npm provenance: the affected packages were last published from a workstation, which has no OIDC token to attest with, so the published tarballs had no attestation. Publishing through the release workflow signs them.

  • Updated dependencies [85e57a7, 74bbf60, e5d31ab, 1fb1cad, d1a3d8c]:

    • @interlace/eslint-devkit@1.8.0

3.1.9

Patch Changes

  • #364 86baa02 Thanks @ofri-peretz! - Add the ecosystem and oxlint marks to the README logo row. Each plugin now leads with Interlace -> its ecosystem (node, nestjs, express, react, mongodb, postgresql, mysql, sqlite, prisma, drizzle, knex, typeorm, sequelize, lambda, vercel, jwt) -> oxlint -> ESLint; the generic quality plugins carry the row without an ecosystem mark. README-only change - no rule behaviour is affected. The patch bump is what carries the new README onto npm, which only refreshes a package README on publish.

3.1.8

Patch Changes

  • #338 dc25c81 Thanks @ofri-peretz! - Re-publish every package so npm carries the optimised artifact

    No source changed. This is a no-op patch whose entire purpose is to ship the artifact the current build already produces.

    Manifests. scripts and devDependencies are now stripped from every published package.json. Neither can do anything in a consumer’s node_modules — npm never runs one and never installs the other — but they shipped in all 27 manifests, cluttered the npm page, and were read by SCA tools scanning installed manifests. No package declares a lifecycle hook, so nothing observable changes. Every published package is bumped so this applies uniformly rather than to a subset.

    Tarballs. 20 packages were last published before the build pipeline changed and still ship AGENTS.md, CHANGELOG.md, JSDoc in the emitted .js, and the full generated .d.ts tree:

    packagepublishedrebuiltsaving
    eslint-plugin-react-features547 kB320 kB−227 kB
    eslint-plugin-secure-coding653 kB477 kB−176 kB
    eslint-plugin-conventions241 kB116 kB−125 kB
    eslint-plugin-browser-security380 kB291 kB−89 kB
    eslint-plugin-maintainability178 kB116 kB−62 kB
    eslint-plugin-react-a11y232 kB173 kB−59 kB
    eslint-plugin-reliability148 kB90 kB−58 kB
    eslint-plugin-vercel-ai-security187 kB130 kB−57 kB
    eslint-plugin-operability90 kB43 kB−47 kB
    eslint-plugin-jwt140 kB95 kB−45 kB
    eslint-plugin-modularity98 kB58 kB−40 kB
    eslint-plugin-nestjs-security122 kB86 kB−36 kB
    eslint-plugin-sqlite-security54 kB20 kB−34 kB
    eslint-plugin-sequelize-security54 kB21 kB−34 kB
    eslint-plugin-prisma-security52 kB19 kB−33 kB
    eslint-plugin-mysql-security52 kB19 kB−33 kB
    eslint-plugin-typeorm-security52 kB19 kB−33 kB
    eslint-plugin-drizzle-security52 kB19 kB−33 kB
    eslint-plugin-knex-security51 kB19 kB−32 kB
    eslint-plugin-modernization45 kB38 kB−7 kB

    Those 20 go from 3428 kB to 2169 kB — −36.7%. The remaining 7 were released after the pipeline change and only gain the manifest strip.

    A new check in scripts/check-published-artifacts.ts fails the build if scripts or devDependencies ever reappear in a published manifest, so the strip cannot silently regress.

    The dependency ranges did not need updating: every plugin pins @interlace/eslint-devkit with a caret that 1.6.0 satisfies, verified by a clean install of an unchanged plugin resolving devkit 1.6.0 with zero dependencies and no typescript in the tree.

  • Updated dependencies [dc25c81]:

    • @interlace/eslint-devkit@1.6.1

3.1.7

Patch Changes

  • #294 659f6dc Thanks @ofri-peretz! - Rewrite description and keywords on every published package for npm search discovery. npm ranks on name, description, and keywords, and the registry only picks up these fields at publish — so this is metadata-only and takes effect for each package on its next release.

    Descriptions now lead with the search phrase. Every one starts ESLint plugin for <the thing you'd search> instead of a brand-first or category-first framing, and names the concrete vulnerabilities the plugin actually detects. Three were corrected while doing so:

    • eslint-plugin-import-next claimed "100x faster no-cycle detection". No 100x measurement exists: CLAIMS.md records 3.1x end-to-end (8x in pure rule execution) on a 5,483-file React codebase, and the highest number in any benchmark result is 54.9x on the synthetic corpus. The description now states the real-codebase figure.
    • eslint-plugin-secure-coding claimed SQL injection, XSS and CSRF coverage — none of which are its rules. It now names what it does detect: LDAP, XPath, XXE, GraphQL and template injection, unsafe deserialization, ReDoS, missing authentication, and PII in logs.
    • eslint-plugin-secure-coding ("89 rules") and eslint-plugin-react-a11y ("37 rules") hard-coded rule counts that had drifted from reality. Counts are generated into interlace-numbers.json; hand-typed copies are removed rather than corrected.

    Keywords now match the vocabulary of the plugins that rank. eslint-plugin-security, eslint-plugin-jsx-a11y, eslint-plugin-n and eslint-plugin-import all carry the eslint / eslintplugin / eslint-plugin trio — six of our packages were missing eslintplugin, and every one now carries all three plus static-analysis, linting and code-quality. Security plugins add sast, appsec and vulnerability; node-security and secure-coding also carry nodesecurity, the exact keyword eslint-plugin-security ranks on. Each plugin gained the CWE identifiers and attack names for what it detects (cwe-78 command injection, cwe-22 path traversal, cwe-89 SQL injection, cwe-79 XSS, cwe-347 JWT algorithm confusion, cwe-352 CSRF, cwe-943 NoSQL injection), and node-security gained the crypto vocabulary it had been missing entirely despite absorbing the crypto rule set (crypto, cryptography, weak-hash, md5, sha1, timing-attack).

    No rule behavior, exports, or configuration changes.

  • Updated dependencies [e1cdf83, 659f6dc]:

    • @interlace/eslint-devkit@1.4.3

3.1.6

Patch Changes

  • #269 7028fe2 Thanks @ofri-peretz! - docs: dual-logo README header (Interlace mark + ESLint mark side by side) and closing Interlace footer — refreshes the README rendered on npmjs.com. No runtime changes.

  • Updated dependencies [7028fe2]:

    • @interlace/eslint-devkit@1.4.2

3.1.5

Patch Changes

  • #252 d67e395 Thanks @ofri-peretz! - Fix Codecov badge showing "unknown" — switch from flag to component URL format

3.1.4

Patch Changes

  • #141 38ab670 Thanks @ofri-peretz! - fix: remove false meta.fixable: 'code' declarations from 21 rules that had no fix() function

    Rules that declared fixable: 'code' in their ESLint meta without an actual fix() implementation would show the ⚡ auto-fix icon in editors and CI formatters but apply no change when --fix was run. This patch removes the misleading declaration from:

    • browser-security/no-clickjacking
    • import-next/first, named, no-barrel-import, no-import-module-exports, no-namespace
    • node-security/no-buffer-overread, no-unsafe-dynamic-require, no-zip-slip
    • react-features/react-no-inline-functions
    • reliability/no-jsdoc-terminator-in-example (uses suggest, not auto-fix; corrected to hasSuggestions: true only)
    • secure-coding/no-directive-injection, no-electron-security-issues, no-graphql-injection, no-improper-sanitization, no-improper-type-validation, no-ldap-injection, no-unchecked-loop-condition, no-unlimited-resource-allocation, no-weak-password-recovery, no-xpath-injection
  • #143 213cde1 Thanks @ofri-peretz! - fix(no-missing-null-checks): eliminate 53 false positives via three new narrowing patterns

    Rules that were recognized as null guards are now correctly identified as safe:

    1. Truthy if guardif (obj) { obj.prop } — direct truthy check proves non-null. Also covers chains: if (response) protects response.data.items.
    2. Short-circuit ANDobj && obj.prop — right side of && only runs when left is truthy.
    3. Ternary consequentobj ? obj.prop : fallback — truthy test guards the consequent.

    Also: bumped beforeAll timeout to 30 seconds in 7 compatibility test files (__compatibility__/*.spec.ts). Native-addon packages routinely exceed the previous 10-second default on a cold ESM load.

  • Updated dependencies [736a5fe]:

    • @interlace/eslint-devkit@1.4.1

Bug Fixes

  • no-missing-null-checks: exempt provably-non-null identifiers (built-in singletons like Math, JSON, console, error classes; catch-clause params; constructor results; top-level imports) from the null-check requirement. Eliminates a large class of false positives without weakening real coverage.
  • no-unhandled-promise: refined detection (see source diff).

3.1.2 (2026-02-09)

This was a version bump only for eslint-plugin-reliability to align it with other projects, there were no code changes.

[3.1.0] - 2026-02-08

This was a version bump only for eslint-plugin-reliability to align it with other projects, there were no code changes.

[3.0.4] - 2026-02-08

Bug Fixes

  • align codecov component IDs with full package names (2831b968)

Documentation

  • fix changelog header format across all packages (c3a15082)

❤️ Thank You

  • Ofri Peretz

[3.0.3] - 2026-02-06

Bug Fixes

  • align codecov component names and update docs components (0a59a86c)

❤️ Thank You

  • Ofri Peretz

[3.0.2] - 2026-02-02

This was a version bump only for eslint-plugin-reliability to align it with other projects, there were no code changes.

Changelog

All notable changes to eslint-plugin-reliability will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

Documentation

  • 📘 Launched new documentation site: eslint.interlace.tools
  • 📝 Achieved 100% documentation parity (both .md and .mdx files)

[3.0.1] - 2026-02-02

This was a version bump only for eslint-plugin-reliability to align it with other projects, there were no code changes.

[3.0.0] - 2026-02-02

This was a version bump only for eslint-plugin-reliability to align it with other projects, there were no code changes.

[1.0.0] - 2026-01-26

Added

  • Initial stable release with 8 reliability rules
  • LLM-optimized error messages for AI-assisted development
  • 100% test coverage across all rules
  • ESLint 9 flat config support
  • TypeScript type definitions for all rule options

Rules

Error Handling (4 rules)

RuleDescriptionCWE
no-unhandled-promiseDetect unhandled promise rejectionsCWE-392
no-silent-errorsDetect empty catch blocks that swallow errorsCWE-390
no-missing-error-contextRequire error context when re-throwingCWE-209
error-messageRequire meaningful error messagesCWE-209

Runtime Safety (4 rules)

RuleDescriptionCWE
no-missing-null-checksDetect potential null/undefined dereferencesCWE-476
no-unsafe-type-narrowingDetect unsafe type narrowing patternsCWE-704
require-network-timeoutRequire timeouts on network requestsCWE-400
no-await-in-loopDetect sequential await in loops (N+1 issues)Performance

Presets

  • recommended - Balanced reliability checks (4 rules as warnings)

Known Limitations

Documented in docs/KNOWN-LIMITATIONS.md:

  • no-unhandled-promises: Promises in callbacks or async iterators may be missed
  • no-silent-errors: Intentional suppression vs. actual swallowing is hard to distinguish
  • no-missing-null-checks: Business-logic guarantees not in types can trigger false positives

Building secure JavaScript with Interlace? Star the repo to get new rules and CWE coverage as we ship them — or follow the AI-code-security benchmarks behind them.

On this page

No Headings