chore(deps): all non-major dependencies #431
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
9.30.0
->9.35.0
1.7.2
->1.11.0
1.2.7
->1.3.1
18.19.113
->18.19.124
5.3.0
->5.3.21
17.0.0
->17.2.2
0.25.5
->0.25.9
9.30.0
->9.35.0
10.1.5
->10.1.8
16.2.0
->16.3.0
0.28.7
->0.28.12
5.8.3
->5.9.2
8.35.1
->8.42.0
7.11.0
->7.15.0
Release Notes
eslint/eslint (@eslint/js)
v9.35.0
Compare Source
v9.34.0
Compare Source
v9.33.0
Compare Source
v9.32.0
Compare Source
v9.31.0
Compare Source
v9.30.1
Compare Source
MoLow/reporters (@reporters/github)
v1.11.0
Compare Source
v1.10.0
Compare Source
v1.9.3
Compare Source
v1.9.2
Compare Source
v1.9.1
Compare Source
v1.9.0
Compare Source
v1.8.0
Compare Source
vercel/vercel (@vercel/node)
v5.3.21
Compare Source
Patch Changes
v5.3.20
Compare Source
Patch Changes
Support package.json#main field as the entrypoint (#13846)
Fix issue where install scripts from project settings didn't pick up the appropriate pnpm version (#13846)
Updated dependencies [
fa9310f879f9e4c72c64bbf542e1e242914f800f
]:v5.3.19
Compare Source
Patch Changes
.mts
to ESM (#13693)v5.3.18
Compare Source
Patch Changes
d1ca3ed3ac1b9830403dc9dc3520e963ef8bec8e
]:v5.3.17
Compare Source
Patch Changes
Add .cts support to express and hono builders (#13828)
Add support for http listener when it's not default exported (#13826)
Fix issue where install scripts from project settings didn't pick up the appropriate pnpm version (#13840)
v5.3.16
Compare Source
Patch Changes
6260486192ca407fc2d91f317ed81533548b8629
]:v5.3.15
Compare Source
Patch Changes
Add support for specifying an output directory for Express and Hono apps (#13805)
[next][node][redwood][remix] bump
@vercel/[email protected]
(#13818)v5.3.14
Compare Source
Patch Changes
28a41c6fddc7a3bc92fa54279063428b329e3104
]:v5.3.13
Compare Source
Patch Changes
v5.3.12
Compare Source
Patch Changes
Add
.mts
support to node builder (#13687)Skip lib check on node dev server (#13696)
Updated dependencies [
8a020e07c2116833bbe39ee43f62efad9f7de0de
]:v5.3.11
Compare Source
Patch Changes
Support fetchable apps out of the box for Node dev server. (#13664)
Support CommonJS for Hono
v5.3.10
Compare Source
Patch Changes
v5.3.8
Compare Source
Patch Changes
v5.3.7
Compare Source
Patch Changes
Adds framework detection and an associated builder for Hono. (#13594)
Updated dependencies [
b79db72d870a8d2e98e36a7413c656ae80fed01f
]:v5.3.6
Compare Source
Patch Changes
Reverting support for
preferredRegion
(#13566)Updated dependencies [
bae121f5ba238a7e98ac6159bc4cf36e23c33142
]:v5.3.5
Compare Source
Patch Changes
f37cd4e2eb35764a658f617643e2ab228191e7e2
]:v5.3.4
Compare Source
Patch Changes
ed2d1c1ea934e803c5e656b1663034176aef2f27
]:v5.3.3
Compare Source
Patch Changes
dc424e1b09230e35f4953e2c4d1ccdab18f57d8c
]:v5.3.2
Compare Source
Patch Changes
v5.3.1
Compare Source
Patch Changes
.mts
to ESM (#13693)motdotla/dotenv (dotenv)
v17.2.2
Compare Source
Added
v17.2.1
Compare Source
Changed
v17.2.0
Compare Source
Added
DOTENV_CONFIG_QUIET=true
in your environment or.env
file to quiet the runtime log (#889)DOTENV_CONFIG_
environment variables take precedence over any code set options like({quiet: false})
v17.1.0
Compare Source
Added
v17.0.1
Compare Source
Changed
evanw/esbuild (esbuild)
v0.25.9
Compare Source
Better support building projects that use Yarn on Windows (#3131, #3663)
With this release, you can now use esbuild to bundle projects that use Yarn Plug'n'Play on Windows on drives other than the
C:
drive. The problem was as follows:C:
driveD:
drive../..
to get from the project directory to the cache directory..
(soD:\..
is justD:
)Yarn works around this edge case by pretending Windows-style paths beginning with
C:\
are actually Unix-style paths beginning with/C:/
, so the../..
path segments are able to navigate across drives inside Yarn's implementation. This was broken for a long time in esbuild but I finally got access to a Windows machine and was able to debug and fix this edge case. So you should now be able to bundle these projects with esbuild.Preserve parentheses around function expressions (#4252)
The V8 JavaScript VM uses parentheses around function expressions as an optimization hint to immediately compile the function. Otherwise the function would be lazily-compiled, which has additional overhead if that function is always called immediately as lazy compilation involves parsing the function twice. You can read V8's blog post about this for more details.
Previously esbuild did not represent parentheses around functions in the AST so they were lost during compilation. With this change, esbuild will now preserve parentheses around function expressions when they are present in the original source code. This means these optimization hints will not be lost when bundling with esbuild. In addition, esbuild will now automatically add this optimization hint to immediately-invoked function expressions. Here's an example:
Note that you do not want to wrap all function expressions in parentheses. This optimization hint should only be used for functions that are called on initial load. Using this hint for functions that are not called on initial load will unnecessarily delay the initial load. Again, see V8's blog post linked above for details.
Update Go from 1.23.10 to 1.23.12 (#4257, #4258)
This should have no effect on existing code as this version change does not change Go's operating system support. It may remove certain false positive reports (specifically CVE-2025-4674 and CVE-2025-47907) from vulnerability scanners that only detect which version of the Go compiler esbuild uses.
v0.25.8
Compare Source
Fix another TypeScript parsing edge case (#4248)
This fixes a regression with a change in the previous release that tries to more accurately parse TypeScript arrow functions inside the
?:
operator. The regression specifically involves parsing an arrow function containing a#private
identifier inside the middle of a?:
ternary operator inside a class body. This was fixed by propagating private identifier state into the parser clone used to speculatively parse the arrow function body. Here is an example of some affected code:Fix a regression with the parsing of source phase imports
The change in the previous release to parse source phase imports failed to properly handle the following cases:
Parsing for these cases should now be fixed. The first case was incorrectly treated as a syntax error because esbuild was expecting the second case. And the last case was previously allowed but is now forbidden. TypeScript hasn't added this feature yet so it remains to be seen whether the last case will be allowed, but it's safer to disallow it for now. At least Babel doesn't allow the last case when parsing TypeScript, and Babel was involved with the source phase import specification.
v0.25.7
Compare Source
Parse and print JavaScript imports with an explicit phase (#4238)
This release adds basic syntax support for the
defer
andsource
import phases in JavaScript:defer
This is a stage 3 proposal for an upcoming JavaScript feature that will provide one way to eagerly load but lazily initialize imported modules. The imported module is automatically initialized on first use. Support for this syntax will also be part of the upcoming release of TypeScript 5.9. The syntax looks like this:
Note that this feature deliberately cannot be used with the syntax
import defer foo from "<specifier>"
orimport defer { foo } from "<specifier>"
.source
This is a stage 3 proposal for an upcoming JavaScript feature that will provide another way to eagerly load but lazily initialize imported modules. The imported module is returned in an uninitialized state. Support for this syntax may or may not be a part of TypeScript 5.9 (see this issue for details). The syntax looks like this:
Note that this feature deliberately cannot be used with the syntax
import defer * as foo from "<specifier>"
orimport defer { foo } from "<specifier>"
.This change only adds support for this syntax. These imports cannot currently be bundled by esbuild. To use these new features with esbuild's bundler, the imported paths must be external to the bundle and the output format must be set to
esm
.Support optionally emitting absolute paths instead of relative paths (#338, #2082, #3023)
This release introduces the
--abs-paths=
feature which takes a comma-separated list of situations where esbuild should use absolute paths instead of relative paths. There are currently three supported situations:code
(comments and string literals),log
(log message text and location info), andmetafile
(the JSON build metadata).Using absolute paths instead of relative paths is not the default behavior because it means that the build results are no longer machine-independent (which means builds are no longer reproducible). Absolute paths can be useful when used with certain terminal emulators that allow you to click on absolute paths in the terminal text and/or when esbuild is being automatically invoked from several different directories within the same script.
Fix a TypeScript parsing edge case (#4241)
This release fixes an edge case with parsing an arrow function in TypeScript with a return type that's in the middle of a
?:
ternary operator. For example:The
:
token in the value assigned tox
pairs with the?
token, so it's not the start of a return type annotation. However, the first:
token in the value assigned toy
is the start of a return type annotation because after parsing the arrow function body, it turns out there's another:
token that can be used to pair with the?
token. This case is notable as it's the first TypeScript edge case that esbuild has needed a backtracking parser to parse. It has been addressed by a quick hack (cloning the whole parser) as it's a rare edge case and esbuild doesn't otherwise need a backtracking parser. Hopefully this is sufficient and doesn't cause any issues.Inline small constant strings when minifying
Previously esbuild's minifier didn't inline string constants because strings can be arbitrarily long, and this isn't necessarily a size win if the string is used more than once. Starting with this release, esbuild will now inline string constants when the length of the string is three code units or less. For example:
Note that esbuild's constant inlining only happens in very restrictive scenarios to avoid issues with TDZ handling. This change doesn't change when esbuild's constant inlining happens. It only expands the scope of it to include certain string literals in addition to numeric and boolean literals.
v0.25.6
Compare Source
Fix a memory leak when
cancel()
is used on a build context (#4231)Calling
rebuild()
followed bycancel()
in rapid succession could previously leak memory. The bundler uses a producer/consumer model internally, and the resource leak was caused by the consumer being termianted while there were still remaining unreceived results from a producer. To avoid the leak, the consumer now waits for all producers to finish before terminating.Support empty
:is()
and:where()
syntax in CSS (#4232)Previously using these selectors with esbuild would generate a warning. That warning has been removed in this release for these cases.
Improve tree-shaking of
try
statements in dead code (#4224)With this release, esbuild will now remove certain
try
statements if esbuild considers them to be within dead code (i.e. code that is known to not ever be evaluated). For example:Consider negated bigints to have no side effects
While esbuild currently considers
1
,-1
, and1n
to all have no side effects, it didn't previously consider-1n
to have no side effects. This is because esbuild does constant folding with numbers but not bigints. However, it meant that unused negative bigint constants were not tree-shaken. With this release, esbuild will now consider these expressions to also be side-effect free:Support a configurable delay in watch mode before rebuilding (#3476, #4178)
The
watch()
API now takes adelay
option that lets you add a delay (in milliseconds) before rebuilding when a change is detected in watch mode. If you use a tool that regenerates multiple source files very slowly, this should make it more likely that esbuild's watch mode won't generate a broken intermediate build before the successful final build. This option is also available via the CLI using the--watch-delay=
flag.This should also help avoid confusion about the
watch()
API's options argument. It was previously empty to allow for future API expansion, which caused some people to think that the documentation was missing. It's no longer empty now that thewatch()
API has an option.Allow mixed array for
entryPoints
API option (#4223)The TypeScript type definitions now allow you to pass a mixed array of both string literals and object literals to the
entryPoints
API option, such as['foo.js', { out: 'lib', in: 'bar.js' }]
. This was always possible to do in JavaScript but the TypeScript type definitions were previously too restrictive.Update Go from 1.23.8 to 1.23.10 (#4204, #4207)
This should have no effect on existing code as this version change does not change Go's operating system support. It may remove certain false positive reports (specifically CVE-2025-4673 and CVE-2025-22874) from vulnerability scanners that only detect which version of the Go compiler esbuild uses.
Experimental support for esbuild on OpenHarmony (#4212)
With this release, esbuild now publishes the
@esbuild/openharmony-arm64
npm package for OpenHarmony. It contains a WebAssembly binary instead of a native binary because Go doesn't currently support OpenHarmony. Node does support it, however, so in theory esbuild should now work on OpenHarmony through WebAssembly.This change was contributed by @hqzing.
eslint/eslint (eslint)
v9.35.0
Compare Source
v9.34.0
Compare Source
v9.33.0
Compare Source
v9.32.0
Compare Source
v9.31.0
Compare Source
v9.30.1
Compare Source
prettier/eslint-config-prettier (eslint-config-prettier)
v10.1.8
Compare Source
eslint-config-prettier
10.1.5
Patch Changes
60fef02
Thanks @JounQin! - chore: addfunding
field intopackage.json
10.1.4
Patch Changes
94b4799
Thanks @silvenon! - fix(cli): do not crash on no rules configured10.1.3
Patch Changes
4e95a1d
Thanks @pilikan! - fix: this package iscommonjs
, align its types correctly10.1.2
Patch Changes
a8768bf
Thanks @Fdawgs! - chore(package): add homepage for some 3rd-party registry - see #321 for more details10.1.1
Patch Changes
#309
eb56a5e
Thanks @JounQin! - fix: separate the/flat
entry for compatibilityFor flat config users, the previous
"eslint-config-prettier"
entry still works, but"eslint-config-prettier/flat"
adds a newname
property for config-inspector, we just can't add it for the default entry for compatibility.See also #308
10.1.0
Minor Changes
56e2e34
Thanks @JounQin! - feat: migrate to exports field10.0.3
Patch Changes
#294
8dbbd6d
Thanks @FloEdelmann! - feat: add name to config#280
cba5737
Thanks @zanminkian! - feat: add declaration file10.0.2
Patch Changes
e750edc
Thanks @Fdawgs! - chore(package): explicitly declare js module type10.0.0
Major Changes
5be64be
Thanks @abrahamguo! - add support for @stylistic formatting rulesVersions before 10.0.0
Version 9.1.0 (2023-12-02)
ESLINT_CONFIG_PRETTIER_NO_DEPRECATED
environment variable.Version 9.0.0 (2023-08-05)
"unicode-bom": "off"
to your config to disable it again, or run ESLint with--fix
to fix all files according to the rule (add or remove BOM). Thanks to Nicolas Stepien (@nstepien)!Version 8.10.0 (2023-08-03)
Version 8.9.0 (2023-07-27)
Version 8.8.0 (2023-03-20)
Version 8.7.0 (2023-03-06)
Version 8.6.0 (2023-01-02)
Version 8.5.0 (2022-03-02)
Version 8.4.0 (2022-02-19)
Version 8.3.0 (2021-04-24)
Version 8.2.0 (2021-04-13)
Version 8.1.0 (2021-02-24)
Version 8.0.0 (2021-02-21)
Changed: All configs have been merged into one!
To upgrade, change:
Into:
The
"prettier"
config now includes not just ESLint core rules, but also rules from all plugins. Much simpler!So … what’s the catch? Why haven’t we done this earlier? Turns out it’s just a sad mistake. I (@lydell) was confused when testing, and thought that turning off unknown rules in a config was an error. Thanks to Georgii Dolzhykov (@thorn0) for pointing this out!
If you use [eslint-plugin-prettier], all you need is [plugin:prettier/recommended]:
(The ["prettier/prettier" config][prettier-prettier-config] still exists separately. It’s the odd one out. The main
"prettier"
config does not include the rules from it.)Changed: The CLI helper tool now only prints warnings for [arrow-body-style] and [prefer-arrow-callback], just like other “special rules.” This means that if you’ve decided to use those rules and [eslint-plugin-prettier] at the same time, you’ll get warnings but exit code zero (success).
Version 7.2.0 (2021-01-18)
Version 7.1.0 (2020-12-19)
Version 7.0.0 (2020-12-05)
Changed: At least ESLint 7.0.0 is now required.
Changed: [arrow-body-style] and [prefer-arrow-callback] are no longer turned off by default. They only need to be turned off if you use [eslint-plugin-prettier]. If you do, add
"prettier/prettier"
to your"extends"
array to turn them off again.Alternatively, update [eslint-plugin-prettier] to version 3.2.0 or later which automatically turns off these two rules in its
"plugin:prettier/recommended"
config.The CLI helper tool only warns about these rules if you have the
"prettier/prettier"
rule enabled for a file.Changed:
no-tabs
is now a validatable rule. If you use it, you should enableallowIndentationTabs
so that the rule works regardless of your Prettier config:Changed: The CLI helper tool is now called just
eslint-config-prettier
instead ofeslint-config-prettier-check
. This is so thatnpx eslint-config-prettier
always works regardless of whether you have already installedeslint-config-prettier
or not: If you have, the local installation is used; if you haven’t,npx
downloads a temporary copy.Changed: The CLI helper tool no longer requires you to pipe the output of
eslint --print-config
to it. Instead, it does that automatically for you via ESLint API:s added in ESLint v7.Before:
After:
Improved: The npm package is now 75% smaller.
Version 6.15.0 (2020-10-27)
Version 6.14.0 (2020-10-21)
Version 6.13.0 (2020-10-16)
Version 6.12.0 (2020-09-25)
Version 6.11.0 (2020-04-21)
Version 6.10.1 (2020-03-22)
npx
when running the CLI helper tool.Version 6.10.0 (2020-01-28)
Version 6.9.0 (2019-12-27)
Version 6.8.0 (2019-12-25)
Version 6.7.0 (2019-11-19)
Version 6.6.0 (2019-11-17)
Version 6.5.0 (2019-10-26)
Version 6.4.0 (2019-10-05)
Version 6.3.0 (2019-09-10)
Version 6.2.0 (2019-09-03)
Version 6.1.0 (2019-08-19)
Version 6.0.0 (2019-06-25)
Changed: The CLI helper tool now considers [no-confusing-arrow] to conflict if you use the default value of its
allowParens
option. The default was changed totrue
in ESLint 6, which conflicts with Prettier.If the CLI helper tool gives you errors about this after upgrading, the solution is to change this:
Into this:
The latter works in both ESLint 6 as well as in ESLint 5 and older.
Improved:
eslint --print-config
usage instructions. The CLI tool help text as well as the documentation has been updated to suggest commands that work in ESLint 6.0 as well as in ESLint 5 and older. (Instead ofeslint --print-config .
, useeslint --print-config path/to/main.js
.)Version 5.1.0 (2019-06-25)
Version 5.0.0 (2019-06-15)
Removed: [react/self-closing-comp]. This rule was added in v4.1.0 not because it conflicted with Prettier but because it was unnecessary when using Prettier. However, in v1.18.0 [Prettier stopped converting empty elements to self-closing elements][prettier-self-closing]. So the rule is not unnecessary anymore.
If you use Prettier v1.17.1 or older you should be able to upgrade eslint-config-prettier to v5.0.0 without having to do anything else.
If you use Prettier v1.18.0 or newer, you might get lint errors about for example changing
<div></div>
into<div />
. You have two options:eslint --fix
if you prefer to enforce self-closing elements where possible. This should fix all the errors."react/self-closing-comp": "off"
to your ESLint config if you use autofix from your editor and you face the same [issue as Prettier did][prettier-self-closing].Changed: Node.js 6 is no longer officially supported, but v5.0.0 should still work with it.
Version 4.3.0 (2019-05-16)
Version 4.2.0 (2019-04-25)
Version 4.1.0 (2019-02-26)
Version 4.0.0 (2019-01-26)
--fix
. They are turned off by default, and the CLI helper tool will warn about them (but not error if you do enable them). This won’t break your linting checks, but do note that these rules will be disabled unless you explicitly enable them again,