recommended and strict. Both include all 16 rules but differ in severity levels.
Recommended config
Userecommended 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 literalsaction-no-invalid-params- Params must use supported types and propertiesaction-no-invalid-timeout-ms- Timeout cannot exceed 900000ms (15 minutes)
action-no-await-handle-result-in-action- Prevents transaction timeouts and billing surprisesaction-no-empty-on-success- Empty exports can be removedaction-no-enqueue-max-concurrency-exceeded- Max concurrency is 100action-no-implicit-enqueue-retries- Gadget defaults to 6 retries, require explicit valueaction-no-return-value-in-on-success- Return values are ignored by Gadgetaction-require-action-run-type- Type annotations improve DXaction-require-explicit-return-type- Return type defaults differ between model and global actionsaction-require-run-with-on-success- onSuccess without run is invalidaction-require-timeout-ms-comment- Improves readability of timeout valuesglobal-action-no-action-type- actionType is not valid in global actionsmodel-action-invalid-action-type- Must be create, update, delete, or custommodel-action-no-invalid-trigger- Model actions cannot use scheduler triggersmodel-action-no-transactional-timeout-mismatch- Transactional actions timeout at 5s regardless of timeoutMS
Strict config
Usestrict 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
Config source code
Both configs are simple rule maps. Here are the actual implementations:Choosing a config
When to use recommended
When to use recommended
- Local development where warnings are acceptable
- Teams adopting the plugin incrementally
- Projects with legacy code that cannot be fixed immediately
- Editor integration (warnings appear inline but do not block saves)
When to use strict
When to use strict
- 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
