Skip to main content
The plugin provides two preset configurations: recommended and strict. Both include all 16 rules but differ in severity levels. Use recommended for most projects. It balances strictness with pragmatism:
eslint.config.js

Severity breakdown

Error-level rules (3): These catch critical validation issues that break Gadget runtime:
  • action-no-invalid-options - Options must be JSON-serializable literals
  • action-no-invalid-params - Params must use supported types and properties
  • action-no-invalid-timeout-ms - Timeout cannot exceed 900000ms (15 minutes)
Warning-level rules (13): These enforce best practices and catch subtle runtime issues:
  • action-no-await-handle-result-in-action - Prevents transaction timeouts and billing surprises
  • action-no-empty-on-success - Empty exports can be removed
  • action-no-enqueue-max-concurrency-exceeded - Max concurrency is 100
  • action-no-implicit-enqueue-retries - Gadget defaults to 6 retries, require explicit value
  • action-no-return-value-in-on-success - Return values are ignored by Gadget
  • action-require-action-run-type - Type annotations improve DX
  • action-require-explicit-return-type - Return type defaults differ between model and global actions
  • action-require-run-with-on-success - onSuccess without run is invalid
  • action-require-timeout-ms-comment - Improves readability of timeout values
  • global-action-no-action-type - actionType is not valid in global actions
  • model-action-invalid-action-type - Must be create, update, delete, or custom
  • model-action-no-invalid-trigger - Model actions cannot use scheduler triggers
  • model-action-no-transactional-timeout-mismatch - Transactional actions timeout at 5s regardless of timeoutMS

Strict config

Use strict for CI, pre-commit hooks, or projects with zero-tolerance for warnings:
eslint.config.js

Severity breakdown

All rules at error level (16): Every rule violation fails the lint run. This is ideal for preventing any non-compliant code from reaching production.

Side-by-side comparison

Rules marked with auto-fix support can be corrected by running eslint --fix.

Config source code

Both configs are simple rule maps. Here are the actual implementations:

Choosing a config

  • CI pipelines (fail builds on any violation)
  • Pre-commit hooks (prevent non-compliant code from being committed)
  • New projects starting with clean slate
  • Production deployments where code quality is critical

Custom severity mix

You can create a custom config by starting with a preset and overriding specific rules:
eslint.config.js

Next steps

Configuration

Learn how to override rules and ignore files

Rules

Read detailed rule documentation