chore: lint changes - #119

False positive: FunctionDeclaration is not in this check, so an await inside a nested async function is attributed to the outer Future.block callback. The same code as an arrow function passes.

Future.block(async $ => {
    async function helper() { await fetch(url); }          // FunctionDeclaration
    return $(Future.fromPromise(helper()));
});

Future.block(async $ => {
    const helper = async () => { await fetch(url); };      // ArrowFunctionExpression
    return $(Future.fromPromise(helper()));
});

yarn lint:

src/lint-demo-1.ts
  6:31  error  Use `await $(...)` inside `Future.block`  local/require-future-block-capture

✖ 1 problem (1 error, 0 warnings)

Suggest adding ancestor.type === "FunctionDeclaration" here.

False negative: when the callback has no capture param or a destructured one the rule skips it, so every await in it goes unreported, and in that case no await can be safe.

Future.block(async () => {
    await fetch(url); // unsafe, but no diagnostic: no capture param
});

Future.block(async ({ length }) => {
    await fetch(url); // unsafe, but no diagnostic: destructured param
    return length;
});

yarn lint: no output, exit 0.

Suggest reporting every AwaitExpression when captureParam is null (message can fall back to $).

configType: "eslintrc" and linter.defineRule are deprecated in ESLint 9 and removed in 10, so the first bump will make this spec throw at construction time. Against eslint@10.11.0:

TypeError: The 'configType' option value must be 'flat'. The value 'eslintrc' is not supported.
    at new Linter (node_modules/eslint/lib/linter/linter.js:790:10)

Flat-config equivalent, mirroring how eslint.config.mjs loads the rule (verified: 3/3 tests pass on 9.39.5, and the same config runs on 10.11.0):

const linter = new Linter();

return linter.verifyAndFix(source, {
    languageOptions: { ecmaVersion: 2022, sourceType: "module" },
    plugins: { local: { rules: { "require-future-block-capture": requireFutureBlockCapture } } },
    rules: { "local/require-future-block-capture": "error" },
});

As this is the first time we do this and we are defining best practices, idea: could we write the rule in TypeScript? .nvmrc pins Node 24 (which has native type stripping), so renaming the rule to .ts and pointing this import at it should just work -> verified with yarn lint, the rule still fires:

src/lint-demo-3.ts
  2:27  error  Use `await $(...)` inside `Future.block`  local/require-future-block-capture

That would let it use ESLintUtils.RuleCreator from @typescript-eslint/utils (already a dependency) instead of untyped context/node, and drop the @ts-expect-error in the spec.

I think writing the rule in TypeScript wold be better. The only downside is that usually downstream projects do not have node updated to latest LTS versions. In those cases, compiling the rules to CommonJS would be an option, but the tradeoff is that linting would have a build prerequisite.

If we continue to add custom rules (or even a preset of existing rules to enforce coding guidelines), the ideal might be having a separate package like @eyeseetea/eslint-plugin, and inside that package have all custom rules written in TypeScript, but publishing the JavaScript compilation. Then the clients would include something like:

import eyeseetea from "@eyeseetea/eslint-plugin";

export default [
    eyeseetea.configs.recommended,
];

Please let me know what do you think, if it is better to move it to TypeSript now (and maybe include a build config for exporting to other projects where node does not support TypeScript), or leave it for a follow-up if we do more extensive work in eslint changes.

I'd keep it simple: Here in the skeleton -> TS. Whenever we want to target a <24 Node -> JS.