chore(deps): update all non-major dependencies #211
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:
^3.0.0
->^3.1.0
^5.47.1
->^5.52.0
^5.47.1
->^5.52.0
^7.12.0
->^7.13.0
0.16.12
->0.17.8
^8.30.0
->^8.34.0
^8.5.0
->^8.6.0
^8.0.2
->^8.0.3
^13.1.0
->^13.1.2
7.21.0
->7.27.0
^8.4.20
->^8.4.21
^2.8.1
->^2.8.4
^4.9.4
->^4.9.5
^1.0.2
->^1.1.2
^4.0.3
->^4.1.2
^0.26.2
->^0.28.5
Release Notes
seek-oss/capsize
v3.1.0
Compare Source
Minor Changes
#117
0e969d8
Thanks @michaeltaranto! - AddcreateFontStack
for metrics-based font family fallbacks.Creates metrics-based
@font-face
declarations to improve the alignment of font family fallbacks, which can dramatically improve the Cumulative Layout Shift metric for sites that depend on a web font.Example usage
The returned values are the computed font family and the generated font face declarations:
Patch Changes
#122
8a15c86
Thanks @michaeltaranto! - Add additional properties toFontMetrics
type definition.Previously the
FontMetrics
type captured only the metrics required by the options for thecreateStyleObject
andcreateStyleString
APIs.With additional APIs coming that require a different subset of metrics, the type now reflects the structure of the data from the
metrics
package.The additional properties are:
familyName
,category
,xHeight
andxWidthAvg
.See documentation for more details.
typescript-eslint/typescript-eslint (@typescript-eslint/eslint-plugin)
v5.52.0
Compare Source
Bug Fixes
Features
v5.51.0
Compare Source
Bug Fixes
Features
verbatimModuleSyntax
(#6394) (b14d3be)v5.50.0
Compare Source
Bug Fixes
String.prototype.length
(#5704) (09d57ce)ThisExpression
andPrivateIdentifier
errors (#6028) (85e783c)Features
key-spacing
rule extension for interface & type declarations (#6211) (67706e7)v5.49.0
Compare Source
Features
#private
modifier on class members (#6259) (c8a6d80)5.48.2 (2023-01-16)
Note: Version bump only for package @typescript-eslint/eslint-plugin
5.48.1 (2023-01-09)
Note: Version bump only for package @typescript-eslint/eslint-plugin
v5.48.2
Compare Source
Note: Version bump only for package @typescript-eslint/eslint-plugin
v5.48.1
Compare Source
Note: Version bump only for package @typescript-eslint/eslint-plugin
v5.48.0
Compare Source
Features
5.47.1 (2022-12-26)
Bug Fixes
typescript-eslint/typescript-eslint (@typescript-eslint/parser)
v5.52.0
Compare Source
Note: Version bump only for package @typescript-eslint/parser
v5.51.0
Compare Source
Note: Version bump only for package @typescript-eslint/parser
v5.50.0
Compare Source
Note: Version bump only for package @typescript-eslint/parser
v5.49.0
Compare Source
Note: Version bump only for package @typescript-eslint/parser
5.48.2 (2023-01-16)
Note: Version bump only for package @typescript-eslint/parser
5.48.1 (2023-01-09)
Note: Version bump only for package @typescript-eslint/parser
v5.48.2
Compare Source
Note: Version bump only for package @typescript-eslint/parser
v5.48.1
Compare Source
Note: Version bump only for package @typescript-eslint/parser
v5.48.0
Compare Source
Note: Version bump only for package @typescript-eslint/parser
5.47.1 (2022-12-26)
Note: Version bump only for package @typescript-eslint/parser
bcoe/c8
v7.13.0
Compare Source
Features
skipFull
andexcludeNodeModules
to type definitions (#417) (b93b9c0)evanw/esbuild
v0.17.8
Compare Source
Fix a minification bug with non-ASCII identifiers (#2910)
This release fixes a bug with esbuild where non-ASCII identifiers followed by a keyword were incorrectly not separated by a space. This bug affected both the
in
andinstanceof
keywords. Here's an example of the fix:Fix a regression with esbuild's WebAssembly API in version 0.17.6 (#2911)
Version 0.17.6 of esbuild updated the Go toolchain to version 1.20.0. This had the unfortunate side effect of increasing the amount of stack space that esbuild uses (presumably due to some changes to Go's WebAssembly implementation) which could cause esbuild's WebAssembly-based API to crash with a stack overflow in cases where it previously didn't crash. One such case is the package
grapheme-splitter
which contains code that looks like this:This edge case involves a chain of binary operators that results in an AST over 400 nodes deep. Normally this wouldn't be a problem because Go has growable call stacks, so the call stack would just grow to be as large as needed. However, WebAssembly byte code deliberately doesn't expose the ability to manipulate the stack pointer, so Go's WebAssembly translation is forced to use the fixed-size WebAssembly call stack. So esbuild's WebAssembly implementation is vulnerable to stack overflow in cases like these.
It's not unreasonable for this to cause a stack overflow, and for esbuild's answer to this problem to be "don't write code like this." That's how many other AST-manipulation tools handle this problem. However, it's possible to implement AST traversal using iteration instead of recursion to work around limited call stack space. This version of esbuild implements this code transformation for esbuild's JavaScript parser and printer, so esbuild's WebAssembly implementation is now able to process the
grapheme-splitter
package (at least when compiled with Go 1.20.0 and run with node's WebAssembly implementation).v0.17.7
Compare Source
Change esbuild's parsing of TypeScript instantiation expressions to match TypeScript 4.8+ (#2907)
This release updates esbuild's implementation of instantiation expression erasure to match microsoft/TypeScript#49353. The new rules are as follows (copied from TypeScript's PR description):
Ignore
sideEffects: false
for imported CSS files (#1370, #1458, #2905)This release ignores the
sideEffects
annotation inpackage.json
for CSS files that are imported into JS files using esbuild'scss
loader. This means that these CSS files are no longer be tree-shaken.Importing CSS into JS causes esbuild to automatically create a CSS entry point next to the JS entry point containing the bundled CSS. Previously packages that specified some form of
"sideEffects": false
could potentially cause esbuild to consider one or more of the JS files on the import path to the CSS file to be side-effect free, which would result in esbuild removing that CSS file from the bundle. This was problematic because the removal of that CSS is outwardly observable, since all CSS is global, so it was incorrect for previous versions of esbuild to tree-shake CSS files imported into JS files.Add constant folding for certain additional equality cases (#2394, #2895)
This release adds constant folding for expressions similar to the following:
v0.17.6
Compare Source
Fix a CSS parser crash on invalid CSS (#2892)
Previously the following invalid CSS caused esbuild's parser to crash:
The crash was caused by trying to construct a helpful error message assuming that there was an opening
{
token, which is not the case here. This release fixes the crash.Inline TypeScript enums that are referenced before their declaration
Previously esbuild inlined enums within a TypeScript file from top to bottom, which meant that references to TypeScript enum members were only inlined within the same file if they came after the enum declaration. With this release, esbuild will now inline enums even when they are referenced before they are declared:
This makes esbuild's TypeScript output smaller and faster when processing code that does this. I noticed this issue when I ran the TypeScript compiler's source code through esbuild's bundler. Now that the TypeScript compiler is going to be bundled with esbuild in the upcoming TypeScript 5.0 release, improvements like this will also improve the TypeScript compiler itself!
Fix esbuild installation on Arch Linux (#2785, #2812, #2865)
Someone made an unofficial
esbuild
package for Linux that adds theESBUILD_BINARY_PATH=/usr/bin/esbuild
environment variable to the user's default environment. This breaks all npm installations of esbuild for users with this unofficial Linux package installed, which has affected many people. Most (all?) people who encounter this problem haven't even installed this unofficial package themselves; instead it was installed for them as a dependency of another Linux package. The problematic change to add theESBUILD_BINARY_PATH
environment variable was reverted in the latest version of this unofficial package. However, old versions of this unofficial package are still there and will be around forever. With this release,ESBUILD_BINARY_PATH
is now ignored by esbuild's install script when it's set to the value/usr/bin/esbuild
. This should unbreak using npm to installesbuild
in these problematic Linux environments.Note: The
ESBUILD_BINARY_PATH
variable is an undocumented way to override the location of esbuild's binary when esbuild's npm package is installed, which is necessary to substitute your own locally-built esbuild binary when debugging esbuild's npm package. It's only meant for very custom situations and should absolutely not be forced on others by default, especially without their knowledge. I may remove the code in esbuild's installer that readsESBUILD_BINARY_PATH
in the future to prevent these kinds of issues. It will unfortunately make debugging esbuild harder. IfESBUILD_BINARY_PATH
is ever removed, it will be done in a "breaking change" release.v0.17.5
Compare Source
Parse
const
type parameters from TypeScript 5.0The TypeScript 5.0 beta announcement adds
const
type parameters to the language. You can now add theconst
modifier on a type parameter of a function, method, or class like this:The type of
names
in the above example isreadonly ["Alice", "Bob", "Eve"]
. Marking the type parameter asconst
behaves as if you had writtenas const
at every use instead. The above code is equivalent to the following TypeScript, which was the only option before TypeScript 5.0:You can read the announcement for more information.
Make parsing generic
async
arrow functions more strict in.tsx
filesPreviously esbuild's TypeScript parser incorrectly accepted the following code as valid:
The official TypeScript parser rejects this code because it thinks it's the identifier
async
followed by a JSX element starting with<T>
. So with this release, esbuild will now reject this syntax in.tsx
files too. You'll now have to add a comma after the type parameter to get generic arrow functions like this to parse in.tsx
files:Allow the
in
andout
type parameter modifiers on class expressionsTypeScript 4.7 added the
in
andout
modifiers on the type parameters of classes, interfaces, and type aliases. However, while TypeScript supported them on both class expressions and class statements, previously esbuild only supported them on class statements due to an oversight. This release now allows these modifiers on class expressions too:Update
enum
constant folding for TypeScript 5.0TypeScript 5.0 contains an updated definition of what it considers a constant expression:
This impacts esbuild's implementation of TypeScript's
const enum
feature. With this release, esbuild will now attempt to follow these new rules. For example, you can now initialize anenum
member with a template literal expression that contains a numeric constant:These rules are not followed exactly due to esbuild's limitations. The rule about dotted references to
const
variables is not followed both because esbuild's enum processing is done in an isolated module setting and because doing so would potentially require esbuild to use a type system, which it doesn't have. For example:Also, the rule that requires converting numbers to a string currently only followed for 32-bit signed integers and non-finite numbers. This is done to avoid accidentally introducing a bug if esbuild's number-to-string operation doesn't exactly match the behavior of a real JavaScript VM. Currently esbuild's number-to-string constant folding is conservative for safety.
Forbid definite assignment assertion operators on class methods
In TypeScript, class methods can use the
?
optional property operator but not the!
definite assignment assertion operator (while class fields can use both):Previously esbuild incorrectly allowed the definite assignment assertion operator with class methods. This will no longer be allowed starting with this release.
v0.17.4
Compare Source
Implement HTTP
HEAD
requests in serve mode (#2851)Previously esbuild's serve mode only responded to HTTP
GET
requests. With this release, esbuild's serve mode will also respond to HTTPHEAD
requests, which are just like HTTPGET
requests except that the body of the response is omitted.Permit top-level await in dead code branches (#2853)
Adding top-level await to a file has a few consequences with esbuild:
module
andexports
for exports and also enables strict mode, which disables certain syntax and changes how function hoisting works (among other things).require()
on this file or on any file that imports this file (even indirectly), since therequire()
function doesn't return a promise and so can't represent top-level await.This release relaxes these rules slightly: rules 2 and 3 will now no longer apply when esbuild has identified the code branch as dead code, such as when it's behind an
if (false)
check. This should make it possible to use esbuild to convert code into different output formats that only uses top-level await conditionally. This release does not relax rule 1. Top-level await will still cause esbuild to unconditionally consider the input module format to be ESM, even when the top-levelawait
is in a dead code branch. This is necessary because whether the input format is ESM or not affects the whole file, not just the dead code branch.Fix entry points where the entire file name is the extension (#2861)
Previously if you passed esbuild an entry point where the file extension is the entire file name, esbuild would use the parent directory name to derive the name of the output file. For example, if you passed esbuild a file
./src/.ts
then the output name would besrc.js
. This bug happened because esbuild first strips the file extension to get./src/
and then joins the path with the working directory to get the absolute path (e.g.join("/working/dir", "./src/")
gives/working/dir/src
). However, the join operation also canonicalizes the path which strips the trailing/
. Later esbuild uses the "base name" operation to extract the name of the output file. Since there is no trailing/
, esbuild returns"src"
as the base name instead of""
, which causes esbuild to incorrectly include the directory name in the output file name. This release fixes this bug by deferring the stripping of the file extension until after all path manipulations have been completed. So now the file./src/.ts
will generate an output file named.js
.Support replacing property access expressions with inject
At a high level, this change means the
inject
feature can now replace all of the same kinds of names as thedefine
feature. Soinject
is basically now a more powerful version ofdefine
, instead of previously only being able to do some of the things thatdefine
could do.Soem background is necessary to understand this change if you aren't already familiar with the
inject
feature. Theinject
feature lets you replace references to global variable with a shim. It works like this:inject
featureFor example, if you inject the following file using
--inject:./injected.js
:Then esbuild will replace all references to
process
with theprocessShim
variable, which will causeprocess.cwd()
to return'/'
. This feature is sort of abusing the ESM export alias syntax to specify the mapping of global variables to shims. But esbuild works this way because using this syntax for that purpose is convenient and terse.However, if you wanted to replace a property access expression, the process was more complicated and not as nice. You would have to:
inject
featuredefine
feature to map the property access expression to the random name you made in step 2For example, if you inject the following file using
--inject:./injected2.js --define:process.cwd=someRandomName
:Then esbuild will replace all references to
process.cwd
with thecwdShim
variable, which will also causeprocess.cwd()
to return'/'
(but which this time will not mess with other references toprocess
, which might be desirable).With this release, using the inject feature to replace a property access expression is now as simple as using it to replace an identifier. You can now use JavaScript's "arbitrary module namespace identifier names" feature to specify the property access expression directly using a string literal. For example, if you inject the following file using
--inject:./injected3.js
:Then esbuild will now replace all references to
process.cwd
with thecwdShim
variable, which will also causeprocess.cwd()
to return'/'
(but which will also not mess with other references toprocess
).In addition to inserting a shim for a global variable that doesn't exist, another use case is replacing references to static methods on global objects with cached versions to both minify them better and to make access to them potentially faster. For example:
v0.17.3
Compare Source
Fix incorrect CSS minification for certain rules (#2838)
Certain rules such as
@media
could previously be minified incorrectly. Due to a typo in the duplicate rule checker, two known@
-rules that share the same hash code were incorrectly considered to be equal. This problem was made worse by the rule hashing code considering two unknown declarations (such as CSS variables) to have the same hash code, which also isn't optimal from a performance perspective. Both of these issues have been fixed:v0.17.2
Compare Source
Add
onDispose
to the plugin API (#2140, #2205)If your plugin wants to perform some cleanup after it's no longer going to be used, you can now use the
onDispose
API to register a callback for cleanup-related tasks. For example, if a plugin starts a long-running child process then it may want to terminate that process when the plugin is discarded. Previously there was no way to do this. Here's an example:These
onDispose
callbacks will be called after everybuild()
call regardless of whether the build failed or not as well as after the firstdispose()
call on a given build context.v0.17.1
Compare Source
Make it possible to cancel a build (#2725)
The context object introduced in version 0.17.0 has a new
cancel()
method. You can use it to cancel a long-running build so that you can start a new one without needing to wait for the previous one to finish. When this happens, the previous build should always have at least one error and have no output files (i.e. it will be a failed build).Using it might look something like this:
JS:
Go:
This API is a quick implementation and isn't maximally efficient, so the build may continue to do some work for a little bit before stopping. For example, I have added stop points between each top-level phase of the bundler and in the main module graph traversal loop, but I haven't added fine-grained stop points within the internals of the linker. How quickly esbuild stops can be improved in future releases. This means you'll want to wait for
cancel()
and/or the previousrebuild()
to finish (i.e. await the returned promise in JavaScript) before starting a new build, otherwiserebuild()
will give you the just-canceled build that still hasn't ended yet. Note thatonEnd
callbacks will still be run regardless of whether or not the build was canceled.Fix server-sent events without
servedir
(#2827)The server-sent events for live reload were incorrectly using
servedir
to calculate the path to modified output files. This means events couldn't be sent whenservedir
wasn't specified. This release uses the internal output directory (which is always present) instead ofservedir
(which might be omitted), so live reload should now work whenservedir
is not specified.Custom entry point output paths now work with the
copy
loader (#2828)Entry points can optionally provide custom output paths to change the path of the generated output file. For example,
esbuild foo=abc.js bar=xyz.js --outdir=out
generates the filesout/foo.js
andout/bar.js
. However, this previously didn't work when using thecopy
loader due to an oversight. This bug has been fixed. For example, you can now doesbuild foo=abc.html bar=xyz.html --outdir=out --loader:.html=copy
to generate the filesout/foo.html
andout/bar.html
.The JS API can now take an array of objects (#2828)
Previously it was not possible to specify two entry points with the same custom output path using the JS API, although it was possible to do this with the Go API and the CLI. This will not cause a collision if both entry points use different extensions (e.g. if one uses
.js
and the other uses.css
). You can now pass the JS API an array of objects to work around this API limitation:v0.17.0
Compare Source
This release deliberately contains backwards-incompatible changes. To avoid automatically picking up releases like this, you should either be pinning the exact version of
esbuild
in yourpackage.json
file (recommended) or be using a version range syntax that only accepts patch upgrades such as^0.16.0
or~0.16.0
. See npm's documentation about semver for more information.At a high level, the breaking changes in this release fix some long-standing issues with the design of esbuild's incremental, watch, and serve APIs. This re
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ 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.