chore(deps): update dependency esbuild to v0.21.5 #177
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:
0.21.4->0.21.5Release Notes
evanw/esbuild (esbuild)
v0.21.5Compare Source
Fix
Symbol.metadataon classes without a class decorator (#3781)This release fixes a bug with esbuild's support for the decorator metadata proposal. Previously esbuild only added the
Symbol.metadataproperty to decorated classes if there was a decorator on the class element itself. However, the proposal says that theSymbol.metadataproperty 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
copyloader (#3792)Import attributes (the
withkeyword onimportstatements) are allowed to alter how that path is loaded. For example, esbuild cannot assume that it knows how to load./bagel.jsas typebagel:Because of that, bundling this code with esbuild is an error unless the file
./bagel.jsis 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
copyloader. That's because thecopyloader behaves similarly to--externalin that the file is left external to the bundle. The difference is that thecopyloader copies the file into the output folder and rewrites the import path while--externaldoesn't. That means the following will now work with thecopyloader (such as with--bundle --loader:.bagel=copy):Support import attributes with glob-style imports (#3797)
This release adds support for import attributes (the
withoption) 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: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:
In addition, this change means plugins can now access the contents of
withfor glob-style imports.Support
${configDir}intsconfig.jsonfiles (#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 ofbaseUrlandpathsvalues, which are used by esbuild during bundling to correctly map import paths to file system paths. This feature lets basetsconfig.jsonfiles specified viaextendsrefer to the directory of the top-leveltsconfig.jsonfile. Here is an example:{ "compilerOptions": { "paths": { "js/*": ["${configDir}/dist/js/*"] } } }You can read more in TypeScript's blog post about their upcoming 5.5 release. Note that this feature does not make use of template literals (you need to use
"${configDir}/dist/js/*"not`${configDir}/dist/js/*`). The syntax fortsconfig.jsonis 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)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 theobject-extensionsfeature for the[name]and theobject-accessorsfeature for theget, but esbuild was incorrectly only checking forobject-extensionsand not forobject-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.Configuration
📅 Schedule: Branch creation - "before 4am on Monday" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ 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 Mend Renovate. View repository job log here.