chore: next

.changeset/add_new_option_javascriptjsxeverywhere.md

@@ -0,0 +1,11 @@
+---
+cli: minor
+---
+
+# Add new option `javascript.parser.jsxEverywhere`
+
+This new option allows to control whether Biome should expect JSX syntax in `.js`/`.ts` files.
+
+When `jsxEverywhere` is set to `false`, having JSX syntax like `<div></div>` inside `.js`/`.ts` files will result in a **parsing error**.
+
+This option defaults to `true`.

.changeset/add_the_new_rule_notsignorehttps.md

@@ -0,0 +1,5 @@
+---
+cli: minor
+---
+
+# Add the new rule [`noTsIgnore`](https://biomejs.dev/linter/rules/no-ts-ignore)

.changeset/add_the_new_rule_nounwantedpolyfillio.md

@@ -0,0 +1,5 @@
+---
+cli: minor
+---
+
+# Add the new rule [`noUnwantedPolyfillio`](https://biomejs.dev/linter/rules/no-unwanted-polyfillio)

.changeset/biome_assist.md

@@ -0,0 +1,55 @@
+---
+cli: minor
+---
+
+# Biome assist
+
+Biome assist is a new feature of the Biome analyzer. The assist is meant to provide **actions**. Actions differ from linter rules in that they aren't meant to signal errors.
+
+The assist will provide code actions that users can opt into via configuration or via IDEs/editors, using the Language Server Protocol.
+
+The assist **is enabled by default**.  However, you can turn if off via configuration:
+
+```json
+{
+  "assist": {
+    "enabled": false
+  }
+}
+```
+
+You can turn on the actions that you want to use in your configuration. For example, you can enable the `useSortedKeys` action like this:
+
+```json
+{
+  "assist": {
+    "actions": {
+      "source": {
+        "useSortedKeys": "on"
+      }
+    }
+  }
+}
+```
+
+Alternatively, IDE/editor users can decide which action to apply on save *directly from the editor settings*, as long as the assist is enabled.
+
+For example, in VS Code you can apply the `useSortedKeys` action when saving a file by adding the following snippet in `settings.json`:
+
+```json
+{
+  "editor.codeActionsOnSave": {
+    "source.biome.useSortedKeys": "explicit"
+  }
+}
+```
+
+In Zed, you can achieve the same by adding the following snippet in `~/.config/zed/settings.json`:
+
+```json
+{
+  "code_actions_on_format": {
+    "source.biome.useSortedKeys": true
+  }
+}
+```

.changeset/biome_deserialize_context.md

@@ -0,0 +1,55 @@
+---
+biome_deserialize: minor
+biome_deserialize_macros: minor
+---
+
+# Replace `diagnostics` with `context`
+
+This is a **breaking change**.
+You have to update all manual implementations of the `Deserializable` trait.
+
+All deserialization methods take a `name` parameter.
+This parameter is used to name the deserialized value.
+For instance, in the case of deserialized value from an object field, the name is set to the field name.
+However, this parameter has been abused to pass data such as file names between deserializers.
+
+When we introduced macros to automatically implement `Deserializable`, users request a way of passing the name parameter between deserializers.
+Then, we added the `passthrough_name` attribute to satisfy the request.
+As said before, this was never intended for this usage.
+There are some inherent limitations, notably some deserializers such as the deserializers of `Vec` set `name` to the empty string for all deserialized items.
+
+We now introduce **deserialization context** to provide a proper way to pass a filename or any string identifier to all deserializers.
+All deserializers now take a context parameter that stores this identifier.
+We take the opportunity to integrate diagnostic reporting directly in this deserialization context.
+
+Let's take the deserializer of `Day` presented in the `biome_deserialize` [README](https://github.com/biomejs/biome/tree/main/crates/biome_deserialize) as an example for migrating to the new paradigm.
+You have to remove the `diagnostics` parameter and to add a new `ctx` parameter.
+Note that the diagnostics are now reported using `ctx.report()`.
+
+```diff
+  impl Deserializable for Day {
+      fn deserialize(
++         ctx: &mut impl DeserializationContext,
+          value: &impl DeserializableValue,
+          name: &str,
+-         diagnostics: &mut Vec<DeserializationDiagnostic>,
+      ) -> Option<Self> {
+          // We deserialize the value into a number represented as a string.
+          let value_text = TextNumber::deserialize(ctx, value, name)?;
+          // We attempt to convert the string into a `Day`.
+          value_text.parse::<Day>().map_err(|error| {
+              // If the conversion failed, then we report the error.
+-             diagnostics.push(DeserializationDiagnostic::new(error).with_range(value.range()));
++             ctx.report(DeserializationDiagnostic::new(error).with_range(value.range()));
+          }).ok()
+      }
+  }
+```
+
+Biome provides `DefaultDeserializationContext` as a default implementation of `DeserializationContext`.
+It is the implementation used by `biome_deserialize::deserialize_from_json_ast`, `biome_deserialize::deserialize_from_json_str`, or `biome_deserialize::::deserialize_from_str`.
+The name (renamed `id`) passed as last parameter to `deserialize_from_json_ast` and `deserialize_from_json_str` now corresponds to the identifier that you can retrieve using `ctx.id()`.
+This no longer sets the name of the deserialized root value.
+The name of the deserialized root value is now the empty string.
+
+Also, the `passthrough_name` macro attribute was removed because we now have a way of retrieving an identfiier from the context.

.changeset/biome_deserialize_feature_gates.md

@@ -0,0 +1,19 @@
+---
+biome_deserialize: minor
+---
+
+# Add the `indexmap` Cargo feature
+
+This is a **breaking change**.
+
+Previously, `biome_deserialize` required `serde` and `indexmap` as dependencies.
+Its dependencies are now optional.
+
+If you need the implementation of `Deserializable` for `indexmap::IndexMap` and `indexmap::IndexSet`, then you have to use the `indexmap` feature.
+Update your `Cargo.toml` as follows:
+
+```diff
+  [dependencies]
+- biome_deserialize = { version: "<version>" }
++ biome_deserialize = { version: "<version>", features = ["indexmap"] }
+```

.changeset/biome_deserialize_remove_stringset.md

@@ -0,0 +1,12 @@
+---
+biome_deserialize: minor
+---
+
+# Remove `biome_deserialize::StringSet`
+
+This is a **breaking change**.
+
+`biome_deserialize::StringSet` is now removed.
+Use `indexmap::IndexSet<String>` instead.
+
+As a consequence the cargo feature `schema` has been removed.

.changeset/biome_migrate_eslint_rule_overriding.md

@@ -0,0 +1,38 @@
+---
+biome_cli: minor
+---
+
+# Biome migrate eslint outputs a better overriding behavior
+
+A Biome rule can have multiple ESLint equivalent rules.
+For example, [useLiteralKeys](https://biomejs.dev/linter/rules/use-literal-keys/) has two ESLint equivalent rules: [dot-notation](https://eslint.org/docs/latest/rules/dot-notation) and [@typescript-eslint/dot-notation](https://typescript-eslint.io/rules/dot-notation/).
+
+Previously, Biome wouldn't always enable a Biome rule even if one of its equivalent rules was enabled.
+Now Biome uses the higher severity level of all the equivalent ESLint rules to set the severity level of the Biome rule.
+
+The following ESLint configuration...
+
+```json
+{
+  "rules": {
+    "@typescript-eslint/dot-notation": "error",
+    "dot-notation": "off"
+  }
+}
+```
+
+...is now migrated to...
+
+```json
+{
+  "linter": {
+    "rules": {
+      "complexity": {
+        "useLiteralKeys": "error"
+      }
+    }
+  }
+}
+```
+
+...because `error` is higher than `off`.

.changeset/code_actions_via_ideeditor.md

@@ -0,0 +1,37 @@
+---
+cli: minor
+---
+
+# Code actions via IDE/editor
+
+Biome users can now configure code actions from linter rules as well as assist actions directly in the settings of their IDE/editor.
+
+For example, let's consider the lint rule [`noSwitchDeclarations`](https://biomejs.dev/linter/rules/no-switch-declarations/), which has an unsafe fix.
+Previously, if you wanted to use this rule, you were "forced" to enable it via configuration, and if you wanted to apply its fix when you saved a file, you were forced to mark the fix as safe:
+
+```json
+{
+  "linter": {
+    "rules": {
+      "correctness": {
+        "noSwitchDeclarations": {
+          "level": "error",
+          "fix": "safe"
+        }
+      }
+    }
+  }
+}
+```
+
+Now, you can benefit from the code action without making the fix safe for the entire project. IDEs and editors that are LSP compatible allow to list a series of "filters" or code actions that can be applied on save. In the case of VS Code, you will need to add the following snippet in the `settings.json`:
+
+```json
+{
+  "editor.codeActionsOnSave": {
+    "quickfix.biome.correctness.noSwitchDeclarations": "explicit"
+  }
+}
+```
+
+Upon save, Biome will inform the editor the apply the code action of the rule `noSwitchDeclarations`.

.changeset/enable_rule_with_default_severity.md

@@ -0,0 +1,35 @@
+---
+cli: minor
+---
+
+# Enable rule with default severity
+
+You can now enable lint rules using the default severity suggested by Biome using the new variant `"on"`, when enabling a rule.
+
+For example, the default severity of the rule `style.noVar` is `error`, so you would use `"on"`, and  then linting a code that uses `var`, will result in an error:
+
+```json
+{
+  "linter": {
+    "recommended": false,
+    "rules": {
+      "style": {
+        "noVar": "on"
+      }
+    }
+  }
+}
+```
+
+```js
+// main.js
+var name = "tobias"
+```
+
+The command `biome lint main.js` will result in an error due to the default severity assigned to `noVar`.
+
+Refer to the documentation page of each rule to know their suggested diagnostic severity, or use the command `biome explain <RULE_NAME>`:
+
+```shell
+biome explain noVar
+```

.changeset/introduce_the_domains_linter_feature.md

@@ -0,0 +1,56 @@
+---
+cli: minor
+---
+
+# Introduce the `domains` linter feature
+
+The Biome linter now has a new way to opt-in rules, with a concept called `domains`.
+
+Domains can be seen as concepts shared by different rules.
+
+You can enable and disable multiple rules that belong to a domain. When you assign `"all"`, Biome will enable all the rules, when you assign `"none"`, Biome will disable the rules, when you assign "recommended", Biome will enable all rules of the domain that are recommended.
+
+```json5
+// biome.jsonc
+{
+  "linter": {
+    "domains": {
+      "test": "all", // all rules that belong to this domain are enabled
+      "react": "recommended", // only the recommended rules from this domain are enabled
+      "solid": "none" // rules related to Solid are disabled
+    }
+  }
+}
+```
+
+New domains introduced:
+
+- `test`: it will enable rules:
+  - `noExportsInTest`
+  - `noExcessiveNestedTestSuites`
+  - `noDuplicateTestHooks`
+  - `noFocusedTests`
+  And it will inject the following globals:
+   - `after`
+   - `afterAll`
+   - `afterEach`
+   - `before`
+   - `beforeEach`
+   - `beforeAll`
+   - `describe`
+   - `it`
+   - `expect`
+   - `test`
+- `next`: it will enable rules for Next.js projects:
+  - `useExhaustiveDependencies`
+  - `useHookAtTopLevel`
+  - `noImgElement`
+  - `noHeadImportInDocument`
+  - `noHeadImportInDocument`
+- `react`: it will enable rules for React projects:
+  - `useExhaustiveDependencies`
+  - `useHookAtTopLevel`
+- `solid`: it will enable rules for Solid projects:
+  - `noReactSpecificProps`
+
+For more information regarding how Biome enables rules via domains, please refer to the documentation page of each rule.