@amedia/eslint-config-jest

# @amedia/eslint-config-jest ## 8.0.1 ### Patch Changes - ba575f1: remove dead rule ## 8.0.0 ### Major Changes - d6346cc: Kragl 4.x _Get ready: This release breaks the world._ ESLint 9 introduces a new configuration format (flat config files)[^1] so as we move to ESLint 9 we need to re-do all the ESLint configuration both in this package, and in downstream repos. See the configuration docs for how to setup kragl for your project. [^1]: https://eslint.org/docs/latest/use/configure/configuration-files We are all-in on ECMAScript Modules at Amedia, but have been held back in this repo due to the tools we depend on have lagged behind. Now the world is ready, and we are making the move. Changes that hit the consumer are things like `.prettierrc.cjs` will not work with the `@amedia/prettier-config` package and the consumer needs to move to `prettier.config.js` with ESM syntax. `@amedia/eslint-config` exports an helper function that generates an ESLint configuration that complies with our standards, it supports both toggling options and full-on custom configuration. For example, a TypeScript + Svelte project: ``` import eslintConfig from '@amedia/eslint-config'; export default eslintConfig({ typescript: true, svelte: true, }); ``` We have had a long-standing issue of the LSP hanging when interacting with our Prettier configuration. This was likely due to our Prettier configuration dynamically loading the Svelte plugin if it was necessary. Some versions of Prettier struggle with that, so for kragl 4.x the consumer manually decides if the standard or svelte prettier configuration should be used. Standard: ``` // prettier.config.js export { default } from '@amedia/prettier-config'; ``` Svelte: ``` // prettier.config.js export { svelte as default } from '@amedia/prettier-config'; ``` ## 7.0.4 ### Patch Changes - dbb3437: add two new rules to eslint-base Adding rules may cause previously linted code to fail, though these two rules may be automatically fixed, so running `kragl lint --fix` should resolve the simple cases automatically. The reason for adding a requirement for the `node:` protocol prefix is to make it absolutely clear that this is an internal node module. This makes it easier for the reader to, as one example, immediately spot any node modules that may need polyfill for the browser. The second rules pushes us to use ESM everywhere it is expected by default. All CommonJS code needs to be moved to `.cjs` files, regardless if the module type is "module" or not. This also serves to help us move to a pure ESM based ecosystem for our internal codebase. ## 7.0.3 ### Patch Changes - fc7cb5d: Updates eslint 8.40.0 -> 8.56.0 ## 7.0.2 ### Patch Changes - a1cf31a: drop config exports from kragl-\* packages - a1cf31a: drop esoteric options for lint and format There are many options for lint and format, and most of them are never used. They were added for debugging purposes, and are superfluous after breaking out the runners to standalone kragl tools. This makes the lint and format commands a lot more straight-foward to use as intended, with fewer sharp edges. - a1cf31a: modularize kragl Introduce `kragl-eslint` and `kragl-prettier`, and expose an API so they can be used from `kragl`. The breaking change is that each runner's internal help text is now available under `--help`, e.g. `kragl prettier --help` or `kragl eslint --help`. They will print the help for Prettier and ESLint respectively, and replaces `--prettier-help`. Each command's usage matches the internal tool's, so `--eslint-config` is no longer necessary, just `--config` with suffice. `kragl lint` and `kragl format` serves as shortcuts to run all the configured formatters and runners with it's own options that normalize usage. - a1cf31a: drop config exports from kragl packages ## 7.0.2-next.3 ### Patch Changes - drop esoteric options for lint and format There are many options for lint and format, and most of them are never used. They were added for debugging purposes, and are superfluous after breaking out the runners to standalone kragl tools. This makes the lint and format commands a lot more straight-foward to use as intended, with fewer sharp edges. ## 7.0.2-next.2 ### Patch Changes - drop config exports from kragl packages ## 7.0.2-next.1 ### Patch Changes - b757c43: drop config exports from kragl-\* packages ## 7.0.2-next.0 ### Patch Changes - modularize kragl Introduce `kragl-eslint` and `kragl-prettier`, and expose an API so they can be used from `kragl`. The breaking change is that each runner's internal help text is now available under `--help`, e.g. `kragl prettier --help` or `kragl eslint --help`. They will print the help for Prettier and ESLint respectively, and replaces `--prettier-help`. Each command's usage matches the internal tool's, so `--eslint-config` is no longer necessary, just `--config` with suffice. `kragl lint` and `kragl format` serves as shortcuts to run all the configured formatters and runners with it's own options that normalize usage. ## 7.0.1 ### Patch Changes - c8b9f59: update eslint to 8.40.0 ## 7.0.0 ### Major Changes - b395434: Introduces the Kragl, a tool that makes it easy to use and comply with the Amedia code style and guidelines. Kragl provides commands like `lint` and `format`, which runs multiple tools with a single command, e.g. `lint` would run ESLint, Prettier, e.g. typechecks for TypeScript projects. Projects can use `kragl lint` with zero configuration and get the recommended rules by default (@amedia/prettier-config and @amedia/eslint-config) that attempts to identify the type of project (react/svelte/jest/typescript) and loads the relevant configuration. To get editor integration, projects should add at least two files: `.eslintrc.cjs`: module.exports = require('@amedia/kragl/config/eslint.config.cjs') `prettier.config.cjs`: module.exports = require('@amedia/kragl/config/prettier.config.cjs') To maximise effectiveness, the existing configurations have been changed to be more isolated in terms of scope (e.g. @amedia/eslint-config-react handles react rules only). This makes them easier to maintain, increases clarity about what rules go where, and generally makes them easier to reason about. This makes it a breaking change for consumers of those libraries. The pattern is to make it easier to do this: module.exports = { extends: [ '@amedia/eslint-config-base', '@amedia/eslint-config-react', '@amedia/eslint-config-jest', '@amedia/eslint-config-typescript', 'prettier', ], } And avoid problems where ESLint cannot uniquely reference a plugin or configuration as they should never collide due to duplication.