chore(deps): update dependency esbuild to v0.14.36 #1815
No reviewers
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#1815
Loading…
Reference in New Issue
No description provided.
Delete Branch "renovate/esbuild-0.x"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
0.14.34
->0.14.36
Release Notes
evanw/esbuild
v0.14.36
Compare Source
Revert path metadata validation for now (#2177)
This release reverts the path metadata validation that was introduced in the previous release. This validation has uncovered a potential issue with how esbuild handles
onResolve
callbacks in plugins that will need to be fixed before path metadata validation is re-enabled.v0.14.35
Compare Source
Add support for parsing
typeof
on #private fields from TypeScript 4.7 (#2174)The upcoming version of TypeScript now lets you use
#private
fields intypeof
type expressions:https://devblogs.microsoft.com/typescript/announcing-typescript-4-7-beta/#typeof-on-private-fields
With this release, esbuild can now parse these new type expressions as well. This feature was contributed by @magic-akari.
Add Opera and IE to internal CSS feature support matrix (#2170)
Version 0.14.18 of esbuild added Opera and IE as available target environments, and added them to the internal JS feature support matrix. CSS feature support was overlooked, however. This release adds knowledge of Opera and IE to esbuild's internal CSS feature support matrix:
The fix for this issue was contributed by @sapphi-red.
Change TypeScript class field behavior when targeting ES2022
TypeScript 4.3 introduced a breaking change where class field behavior changes from assign semantics to define semantics when the
target
setting intsconfig.json
is set toESNext
. Specifically, the default value for TypeScript'suseDefineForClassFields
setting when unspecified istrue
if and only iftarget
isESNext
. TypeScript 4.6 introduced another change where this behavior now happens for bothESNext
andES2022
. Presumably this will be the case forES2023
and up as well. With this release, esbuild's behavior has also been changed to match. Now configuring esbuild with--target=es2022
will also cause TypeScript files to use the new class field behavior.Validate that path metadata returned by plugins is consistent
The plugin API assumes that all metadata for the same path returned by a plugin's
onResolve
callback is consistent. Previously this assumption was just assumed without any enforcement. Starting with this release, esbuild will now enforce this by generating a build error if this assumption is violated. The lack of validation has not been an issue (I have never heard of this being a problem), but it still seems like a good idea to enforce it. Here's a simple example of a plugin that generates inconsistentsideEffects
metadata:Since esbuild processes everything in parallel, the set of metadata that ends up being used for a given path is essentially random since it's whatever the task scheduler decides to schedule first. Thus if a plugin does not consistently provide the same metadata for a given path, subsequent builds may return different results. This new validation check prevents this problem.
Here's the new error message that's shown when this happens:
Suggest enabling a missing condition when
exports
map fails (#2163)This release adds another suggestion to the error message that happens when an
exports
map lookup fails if the failure could potentially be fixed by adding a missing condition. Here's what the new error message looks like (which now suggests--conditions=module
as a possible workaround):This particular package had an issue where it was using the Webpack-specific
module
condition without providing adefault
condition. It looks like the intent in this case was to use the standardimport
condition instead. This specific change wasn't suggested here because this error message is for package consumers, not package authors.Configuration
📅 Schedule: 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.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.
Hi renovate!
Thank you for creating a PR!
I've deployed the changes of this PR on a preview environment under this URL: https://1815-renovate-esbuild-0-x--vikunja-frontend-preview.netlify.app
You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.
Have a nice day!
chore(deps): update dependency esbuild to v0.14.35to chore(deps): update dependency esbuild to v0.14.36cc9282ca75
toe7ea28209b