The plugin provides two preset configurations:Documentation Index
Fetch the complete documentation index at: https://mintlify.com/aurelienbobenrieth/gadget/llms.txt
Use this file to discover all available pages before exploring further.
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
| Rule | Recommended | Strict | Auto-fix |
|---|---|---|---|
action-no-await-handle-result-in-action | warn | error | no |
action-no-empty-on-success | warn | error | yes |
action-no-enqueue-max-concurrency-exceeded | warn | error | no |
action-no-implicit-enqueue-retries | warn | error | no |
action-no-invalid-options | error | error | yes |
action-no-invalid-params | error | error | no |
action-no-invalid-timeout-ms | error | error | yes |
action-no-return-value-in-on-success | warn | error | yes |
action-require-action-run-type | warn | error | yes |
action-require-explicit-return-type | warn | error | yes |
action-require-run-with-on-success | warn | error | no |
action-require-timeout-ms-comment | warn | error | yes |
global-action-no-action-type | warn | error | yes |
model-action-invalid-action-type | warn | error | no |
model-action-no-invalid-trigger | warn | error | yes |
model-action-no-transactional-timeout-mismatch | warn | error | no |
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
