typescript-eslint/typescript-eslint (@typescript-eslint/eslint-plugin)
### [`v7.13.0`](https://togithub.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/eslint-plugin/CHANGELOG.md#7130-2024-06-10)
[Compare Source](https://togithub.com/typescript-eslint/typescript-eslint/compare/v7.12.0...v7.13.0)
##### 🚀 Features
- **typescript-estree:** require `import = require()` argument to be a string literal
- **typescript-estree:** forbid `.body`, `.async`, `.generator` on `declare function`
- **eslint-plugin:** \[no-dynamic-delete] allow all string literals as index
##### 🩹 Fixes
- **ast-spec:** function-call-like callee should be Expression not LeftHandSideExpression
- **scope-manager:** handle index signature in class
- **eslint-plugin:** \[init-declarations] refine report locations
- **eslint-plugin:** \[no-base-to-string] make error message more nuanced
- **eslint-plugin:** \[no-unsafe-assignment] be more specific about error types
- **eslint-plugin:** \[no-magic-numbers] fix implementation of the `ignore` option
##### ❤️ Thank You
- Fotis Papadogeorgopoulos
- Joshua Chen
- Kirk Waiblinger
- Tobiloba Adedeji
- Vinccool96
- YeonJuan
You can read about our [versioning strategy](https://main--typescript-eslint.netlify.app/users/versioning) and [releases](https://main--typescript-eslint.netlify.app/users/releases) on our website.
typescript-eslint/typescript-eslint (@typescript-eslint/parser)
### [`v7.13.0`](https://togithub.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/parser/CHANGELOG.md#7130-2024-06-10)
[Compare Source](https://togithub.com/typescript-eslint/typescript-eslint/compare/v7.12.0...v7.13.0)
##### 🚀 Features
- **parser, typescript-estree:** export withoutProjectParserOptions utility
##### ❤️ Thank You
- Fotis Papadogeorgopoulos
- Joshua Chen
- Kirk Waiblinger
- Tobiloba Adedeji
- Vinccool96
- YeonJuan
You can read about our [versioning strategy](https://main--typescript-eslint.netlify.app/users/versioning) and [releases](https://main--typescript-eslint.netlify.app/users/releases) on our website.
evanw/esbuild (esbuild)
### [`v0.21.5`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0215)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.21.4...v0.21.5)
- Fix `Symbol.metadata` on classes without a class decorator ([#3781](https://togithub.com/evanw/esbuild/issues/3781))
This release fixes a bug with esbuild's support for the [decorator metadata proposal](https://togithub.com/tc39/proposal-decorator-metadata). Previously esbuild only added the `Symbol.metadata` property to decorated classes if there was a decorator on the class element itself. However, the proposal says that the `Symbol.metadata` property should be present on all classes that have any decorators at all, not just those with a decorator on the class element itself.
- Allow unknown import attributes to be used with the `copy` loader ([#3792](https://togithub.com/evanw/esbuild/issues/3792))
Import attributes (the `with` keyword on `import` statements) are allowed to alter how that path is loaded. For example, esbuild cannot assume that it knows how to load `./bagel.js` as type `bagel`:
```js
// This is an error with "--bundle" without also using "--external:./bagel.js"
import tasty from "./bagel.js" with { type: "bagel" }
```
Because of that, bundling this code with esbuild is an error unless the file `./bagel.js` is external to the bundle (such as with `--bundle --external:./bagel.js`).
However, there is an additional case where it's ok for esbuild to allow this: if the file is loaded using the `copy` loader. That's because the `copy` loader behaves similarly to `--external` in that the file is left external to the bundle. The difference is that the `copy` loader copies the file into the output folder and rewrites the import path while `--external` doesn't. That means the following will now work with the `copy` loader (such as with `--bundle --loader:.bagel=copy`):
```js
// This is no longer an error with "--bundle" and "--loader:.bagel=copy"
import tasty from "./tasty.bagel" with { type: "bagel" }
```
- Support import attributes with glob-style imports ([#3797](https://togithub.com/evanw/esbuild/issues/3797))
This release adds support for import attributes (the `with` option) to glob-style imports (dynamic imports with certain string literal patterns as paths). These imports previously didn't support import attributes due to an oversight. So code like this will now work correctly:
```ts
async function loadLocale(locale: string): Locale {
const data = await import(`./locales/${locale}.data`, { with: { type: 'json' } })
return unpackLocale(locale, data)
}
```
Previously this didn't work even though esbuild normally supports forcing the JSON loader using an import attribute. Attempting to do this used to result in the following error:
✘ [ERROR] No loader is configured for ".data" files: locales/en-US.data
example.ts:2:28:
2 │ const data = await import(`./locales/${locale}.data`, { with: { type: 'json' } })
╵ ~~~~~~~~~~~~~~~~~~~~~~~~~~
In addition, this change means plugins can now access the contents of `with` for glob-style imports.
- Support `${configDir}` in `tsconfig.json` files ([#3782](https://togithub.com/evanw/esbuild/issues/3782))
This adds support for a new feature from the upcoming TypeScript 5.5 release. The character sequence `${configDir}` is now respected at the start of `baseUrl` and `paths` values, which are used by esbuild during bundling to correctly map import paths to file system paths. This feature lets base `tsconfig.json` files specified via `extends` refer to the directory of the top-level `tsconfig.json` file. Here is an example:
```json
{
"compilerOptions": {
"paths": {
"js/*": ["${configDir}/dist/js/*"]
}
}
}
```
You can read more in [TypeScript's blog post about their upcoming 5.5 release](https://devblogs.microsoft.com/typescript/announcing-typescript-5-5-rc/#the-configdir-template-variable-for-configuration-files). Note that this feature does not make use of template literals (you need to use `"${configDir}/dist/js/*"` not `` `${configDir}/dist/js/*` ``). The syntax for `tsconfig.json` is still just JSON with comments, and JSON syntax does not allow template literals. This feature only recognizes `${configDir}` in strings for certain path-like properties, and only at the beginning of the string.
- Fix internal error with `--supported:object-accessors=false` ([#3794](https://togithub.com/evanw/esbuild/issues/3794))
This release fixes a regression in 0.21.0 where some code that was added to esbuild's internal runtime library of helper functions for JavaScript decorators fails to parse when you configure esbuild with `--supported:object-accessors=false`. The reason is that esbuild introduced code that does `{ get [name]() {} }` which uses both the `object-extensions` feature for the `[name]` and the `object-accessors` feature for the `get`, but esbuild was incorrectly only checking for `object-extensions` and not for `object-accessors`. Additional tests have been added to avoid this type of issue in the future. A workaround for this issue in earlier releases is to also add `--supported:object-extensions=false`.
okonet/lint-staged (lint-staged)
### [`v15.2.7`](https://togithub.com/okonet/lint-staged/blob/HEAD/CHANGELOG.md#1527)
[Compare Source](https://togithub.com/okonet/lint-staged/compare/v15.2.6...v15.2.7)
##### Patch Changes
- [#1440](https://togithub.com/lint-staged/lint-staged/pull/1440) [`a51be80`](https://togithub.com/lint-staged/lint-staged/commit/a51be804b63307ac7af3c82f4cb2d43dbe92daac) Thanks [@iiroj](https://togithub.com/iiroj)! - In the previous version the native `git rev-parse --show-toplevel` command was taken into use for resolving the current git repo root. This version drops the `--path-format=absolute` option to support earlier git versions since it's also the default behavior. If you are still having trouble, please try upgrading `git` to the latest version.
### [`v15.2.6`](https://togithub.com/okonet/lint-staged/blob/HEAD/CHANGELOG.md#1526)
[Compare Source](https://togithub.com/okonet/lint-staged/compare/v15.2.5...v15.2.6)
##### Patch Changes
- [#1433](https://togithub.com/lint-staged/lint-staged/pull/1433) [`119adb2`](https://togithub.com/lint-staged/lint-staged/commit/119adb29854cabddbfcf0469d7c8a0126184a5d4) Thanks [@iiroj](https://togithub.com/iiroj)! - Use native "git rev-parse" commands to determine git repo root directory and the .git config directory, instead of using custom logic. This hopefully makes path resolution more robust on non-POSIX systems.
prettier/prettier (prettier)
### [`v3.3.2`](https://togithub.com/prettier/prettier/blob/HEAD/CHANGELOG.md#332)
[Compare Source](https://togithub.com/prettier/prettier/compare/3.3.1...3.3.2)
[diff](https://togithub.com/prettier/prettier/compare/3.3.1...3.3.2)
##### Fix handlebars path expressions starts with `@` ([#16358](https://togithub.com/prettier/prettier/pull/16358) by [@Princeyadav05](https://togithub.com/Princeyadav05))
```hbs
{{! Input }}
This PR contains the following updates:
^7.12.0->^7.13.0^7.12.0->^7.13.0^0.21.4->^0.21.5^15.2.5->^15.2.7^3.3.1->^3.3.24.2.2->4.3.0Release Notes
typescript-eslint/typescript-eslint (@typescript-eslint/eslint-plugin)
### [`v7.13.0`](https://togithub.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/eslint-plugin/CHANGELOG.md#7130-2024-06-10) [Compare Source](https://togithub.com/typescript-eslint/typescript-eslint/compare/v7.12.0...v7.13.0) ##### 🚀 Features - **typescript-estree:** require `import = require()` argument to be a string literal - **typescript-estree:** forbid `.body`, `.async`, `.generator` on `declare function` - **eslint-plugin:** \[no-dynamic-delete] allow all string literals as index ##### 🩹 Fixes - **ast-spec:** function-call-like callee should be Expression not LeftHandSideExpression - **scope-manager:** handle index signature in class - **eslint-plugin:** \[init-declarations] refine report locations - **eslint-plugin:** \[no-base-to-string] make error message more nuanced - **eslint-plugin:** \[no-unsafe-assignment] be more specific about error types - **eslint-plugin:** \[no-magic-numbers] fix implementation of the `ignore` option ##### ❤️ Thank You - Fotis Papadogeorgopoulos - Joshua Chen - Kirk Waiblinger - Tobiloba Adedeji - Vinccool96 - YeonJuan You can read about our [versioning strategy](https://main--typescript-eslint.netlify.app/users/versioning) and [releases](https://main--typescript-eslint.netlify.app/users/releases) on our website.typescript-eslint/typescript-eslint (@typescript-eslint/parser)
### [`v7.13.0`](https://togithub.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/parser/CHANGELOG.md#7130-2024-06-10) [Compare Source](https://togithub.com/typescript-eslint/typescript-eslint/compare/v7.12.0...v7.13.0) ##### 🚀 Features - **parser, typescript-estree:** export withoutProjectParserOptions utility ##### ❤️ Thank You - Fotis Papadogeorgopoulos - Joshua Chen - Kirk Waiblinger - Tobiloba Adedeji - Vinccool96 - YeonJuan You can read about our [versioning strategy](https://main--typescript-eslint.netlify.app/users/versioning) and [releases](https://main--typescript-eslint.netlify.app/users/releases) on our website.evanw/esbuild (esbuild)
### [`v0.21.5`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0215) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.21.4...v0.21.5) - Fix `Symbol.metadata` on classes without a class decorator ([#3781](https://togithub.com/evanw/esbuild/issues/3781)) This release fixes a bug with esbuild's support for the [decorator metadata proposal](https://togithub.com/tc39/proposal-decorator-metadata). Previously esbuild only added the `Symbol.metadata` property to decorated classes if there was a decorator on the class element itself. However, the proposal says that the `Symbol.metadata` property should be present on all classes that have any decorators at all, not just those with a decorator on the class element itself. - Allow unknown import attributes to be used with the `copy` loader ([#3792](https://togithub.com/evanw/esbuild/issues/3792)) Import attributes (the `with` keyword on `import` statements) are allowed to alter how that path is loaded. For example, esbuild cannot assume that it knows how to load `./bagel.js` as type `bagel`: ```js // This is an error with "--bundle" without also using "--external:./bagel.js" import tasty from "./bagel.js" with { type: "bagel" } ``` Because of that, bundling this code with esbuild is an error unless the file `./bagel.js` is external to the bundle (such as with `--bundle --external:./bagel.js`). However, there is an additional case where it's ok for esbuild to allow this: if the file is loaded using the `copy` loader. That's because the `copy` loader behaves similarly to `--external` in that the file is left external to the bundle. The difference is that the `copy` loader copies the file into the output folder and rewrites the import path while `--external` doesn't. That means the following will now work with the `copy` loader (such as with `--bundle --loader:.bagel=copy`): ```js // This is no longer an error with "--bundle" and "--loader:.bagel=copy" import tasty from "./tasty.bagel" with { type: "bagel" } ``` - Support import attributes with glob-style imports ([#3797](https://togithub.com/evanw/esbuild/issues/3797)) This release adds support for import attributes (the `with` option) to glob-style imports (dynamic imports with certain string literal patterns as paths). These imports previously didn't support import attributes due to an oversight. So code like this will now work correctly: ```ts async function loadLocale(locale: string): Locale { const data = await import(`./locales/${locale}.data`, { with: { type: 'json' } }) return unpackLocale(locale, data) } ``` Previously this didn't work even though esbuild normally supports forcing the JSON loader using an import attribute. Attempting to do this used to result in the following error: ✘ [ERROR] No loader is configured for ".data" files: locales/en-US.data example.ts:2:28: 2 │ const data = await import(`./locales/${locale}.data`, { with: { type: 'json' } }) ╵ ~~~~~~~~~~~~~~~~~~~~~~~~~~ In addition, this change means plugins can now access the contents of `with` for glob-style imports. - Support `${configDir}` in `tsconfig.json` files ([#3782](https://togithub.com/evanw/esbuild/issues/3782)) This adds support for a new feature from the upcoming TypeScript 5.5 release. The character sequence `${configDir}` is now respected at the start of `baseUrl` and `paths` values, which are used by esbuild during bundling to correctly map import paths to file system paths. This feature lets base `tsconfig.json` files specified via `extends` refer to the directory of the top-level `tsconfig.json` file. Here is an example: ```json { "compilerOptions": { "paths": { "js/*": ["${configDir}/dist/js/*"] } } } ``` You can read more in [TypeScript's blog post about their upcoming 5.5 release](https://devblogs.microsoft.com/typescript/announcing-typescript-5-5-rc/#the-configdir-template-variable-for-configuration-files). Note that this feature does not make use of template literals (you need to use `"${configDir}/dist/js/*"` not `` `${configDir}/dist/js/*` ``). The syntax for `tsconfig.json` is still just JSON with comments, and JSON syntax does not allow template literals. This feature only recognizes `${configDir}` in strings for certain path-like properties, and only at the beginning of the string. - Fix internal error with `--supported:object-accessors=false` ([#3794](https://togithub.com/evanw/esbuild/issues/3794)) This release fixes a regression in 0.21.0 where some code that was added to esbuild's internal runtime library of helper functions for JavaScript decorators fails to parse when you configure esbuild with `--supported:object-accessors=false`. The reason is that esbuild introduced code that does `{ get [name]() {} }` which uses both the `object-extensions` feature for the `[name]` and the `object-accessors` feature for the `get`, but esbuild was incorrectly only checking for `object-extensions` and not for `object-accessors`. Additional tests have been added to avoid this type of issue in the future. A workaround for this issue in earlier releases is to also add `--supported:object-extensions=false`.okonet/lint-staged (lint-staged)
### [`v15.2.7`](https://togithub.com/okonet/lint-staged/blob/HEAD/CHANGELOG.md#1527) [Compare Source](https://togithub.com/okonet/lint-staged/compare/v15.2.6...v15.2.7) ##### Patch Changes - [#1440](https://togithub.com/lint-staged/lint-staged/pull/1440) [`a51be80`](https://togithub.com/lint-staged/lint-staged/commit/a51be804b63307ac7af3c82f4cb2d43dbe92daac) Thanks [@iiroj](https://togithub.com/iiroj)! - In the previous version the native `git rev-parse --show-toplevel` command was taken into use for resolving the current git repo root. This version drops the `--path-format=absolute` option to support earlier git versions since it's also the default behavior. If you are still having trouble, please try upgrading `git` to the latest version. ### [`v15.2.6`](https://togithub.com/okonet/lint-staged/blob/HEAD/CHANGELOG.md#1526) [Compare Source](https://togithub.com/okonet/lint-staged/compare/v15.2.5...v15.2.6) ##### Patch Changes - [#1433](https://togithub.com/lint-staged/lint-staged/pull/1433) [`119adb2`](https://togithub.com/lint-staged/lint-staged/commit/119adb29854cabddbfcf0469d7c8a0126184a5d4) Thanks [@iiroj](https://togithub.com/iiroj)! - Use native "git rev-parse" commands to determine git repo root directory and the .git config directory, instead of using custom logic. This hopefully makes path resolution more robust on non-POSIX systems.prettier/prettier (prettier)
### [`v3.3.2`](https://togithub.com/prettier/prettier/blob/HEAD/CHANGELOG.md#332) [Compare Source](https://togithub.com/prettier/prettier/compare/3.3.1...3.3.2) [diff](https://togithub.com/prettier/prettier/compare/3.3.1...3.3.2) ##### Fix handlebars path expressions starts with `@` ([#16358](https://togithub.com/prettier/prettier/pull/16358) by [@Princeyadav05](https://togithub.com/Princeyadav05)) ```hbs {{! Input }}yarnpkg/berry (yarn)
### [`v4.3.0`](https://togithub.com/yarnpkg/berry/compare/effc932614d5351bbfeed8e0e6aa4b2c6c52821d...b2eb9dce084f1a892101d1b693fea25f05428ff8) [Compare Source](https://togithub.com/yarnpkg/berry/compare/effc932614d5351bbfeed8e0e6aa4b2c6c52821d...b2eb9dce084f1a892101d1b693fea25f05428ff8)Configuration
📅 Schedule: Branch creation - "before 12pm on Sunday" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Mend Renovate. View repository job log here.