-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
📦 Update core devDependencies (minor) #33200
📦 Update core devDependencies (minor) #33200
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It keeps opening new PRs, so I'm just going to leave this one open and block. We can't upgrade karma-esbuild until evanw/esbuild#941 is released in esbuild. Upgrading will cause the test watcher to hang after an edit.
1f15f1d
to
d4c030c
Compare
I now see why you replied in all caps in #33198 (comment) 😃 Yep, a blocking review is the best way to hold off an upgrade until a new version is published. |
29c7ca7
to
d5e56cc
Compare
@jridgewell This is now included in v0.9.1. (See updated PR description.) Okay to merge? |
d5e56cc
to
4d8457c
Compare
5a081b3
to
30ecb6c
Compare
30ecb6c
to
d44653b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice!
This reverts commit 024d795.
This PR contains the following updates:
0.8.57
->0.9.3
0.4.0
->0.5.0
6.1.1
->6.2.0
2.0.0
->2.1.1
How to resolve breaking changes
This PR may introduce breaking changes that require manual intervention. In such cases, you will need to check out this branch, fix the cause of the breakage, and commit the fix to ensure a green CI build. To check out and update this PR, follow the steps below:
Release Notes
evanw/esbuild
v0.9.3
Compare Source
Fix path resolution with the
exports
field for scoped packagesThis release fixes a bug where the
exports
field inpackage.json
files was not being detected for scoped packages (i.e. packages of the form@scope/pkg-name
instead of justpkg-name
). Theexports
field should now be respected for these kinds of packages.Improved error message in
exports
failure caseNode's new conditional exports feature can be non-intuitive and hard to use. Now that esbuild supports this feature (as of version 0.9.0), you can get into a situation where it's impossible to import a package if the package's
exports
field in itspackage.json
file isn't configured correctly.Previously the error message for this looked like this:
With this release, the error message will now provide additional information about why the package cannot be imported:
In this case, one solution could be import this module using
require()
since this package provides an export for therequire
condition. Another solution could be to pass--conditions=module
to esbuild since this package provides an export for themodule
condition (thetypes
condition is likely not valid JavaScript code).This problem occurs because this package doesn't provide an import path for ESM code using the
import
condition and also doesn't provide a fallback import path using thedefault
condition.Mention glob syntax in entry point error messages (#976)
In this release, including a
*
in the entry point path now causes the failure message to tell you that glob syntax must be expanded first before passing the paths to esbuild. People that hit this are usually converting an existing CLI command to a JavaScript API call and don't know that glob expansion is done by their shell instead of by esbuild. An appropriate fix is to use a library such asglob
to expand the glob pattern first before passing the paths to esbuild.Raise certain VM versions in the JavaScript feature compatibility table
JavaScript VM feature compatibility data is derived from this dataset: https://kangax.github.io/compat-table/. The scripts that process the dataset expand the data to include all VM versions that support a given feature (e.g.
chrome44
,chrome45
,chrome46
, ...) so esbuild takes the minimum observed version as the first version for which the feature is supported.However, some features can have subtests that each check a different aspect of the feature. In this case the desired version is the minimum version within each individual subtest, but the maximum of those versions across all subtests (since esbuild should only use the feature if it works in all cases). Previously esbuild computed the minimum version across all subtests, but now esbuild computes the maximum version across all subtests. This means esbuild will now lower JavaScript syntax in more cases.
Mention the configured target environment in error messages (#975)
Using newer JavaScript syntax with an older target environment (e.g.
chrome10
) can cause a build error if esbuild doesn't support transforming that syntax such that it is compatible with that target environment. Previously the error message was generic but with this release, the target environment is called outp explicitly in the error message. This is helpful if esbuild is being wrapped by some other tool since the other tool can obscure what target environment is actually being passed to esbuild.Fix an issue with Unicode and source maps
This release fixes a bug where non-ASCII content that ended up in an output file but that was not part of an input file could throw off source mappings. An example of this would be passing a string containing non-ASCII characters to the
globalName
setting with theminify
setting active and thecharset
setting set toutf8
. The conditions for this bug are fairly specific and unlikely to be hit, so it's unsurprising that this issue hasn't been discovered earlier. It's also unlikely that this issue affected real-world code.The underlying cause is that while the meaning of column numbers in source maps is undefined in the specification, in practice most tools treat it as the number of UTF-16 code units from the start of the line. The bug happened because column increments for outside-of-file characters were incorrectly counted using byte offsets instead of UTF-16 code unit counts.
v0.9.2
Compare Source
Fix export name annotations in CommonJS output for node (#960)
The previous release introduced a regression that caused a syntax error when building ESM files that have a default export with
--platform=node
. This is because the generated export contained thedefault
keyword like this:0 && (module.exports = {default});
. This regression has been fixed.v0.9.1
Compare Source
Fix bundling when parent directory is inaccessible (#938)
Previously bundling with esbuild when a parent directory is inaccessible did not work because esbuild would try to read the directory to search for a
node_modules
folder and would then fail the build when that failed. In practice this caused issues in certain Linux environments where a directory close to the root directory was inaccessible (e.g. on Android). With this release, esbuild will treat inaccessible directories as empty to allow for thenode_modules
search to continue past the inaccessible directory and into its parent directory. This means it should now be possible to bundle with esbuild in these situations.Avoid allocations in JavaScript API stdout processing (#941)
This release improves the efficiency of the JavaScript API. The API runs the binary esbuild executable in a child process and then communicates with it over stdin/stdout. Previously the stdout buffer containing the remaining partial message was copied after each batch of messages due to a bug. This was unintentional and unnecessary, and has been removed. Now this part of the code no longer involves any allocations. This fix was contributed by @jridgewell.
Support conditional
@import
syntax when not bundling (#953)Previously conditional CSS imports such as
@import "print.css" print;
was not supported at all and was considered a syntax error. With this release, it is now supported in all cases except when bundling an internal import. Support for bundling internal CSS imports is planned but will happen in a later release.Always lower object spread and rest when targeting V8 (#951)
This release causes object spread (e.g.
a = {...b}
) and object rest (e.g.{...a} = b
) to always be lowered to a manual implementation instead of using native syntax when the--target=
parameter includes a V8-based JavaScript runtime such aschrome
,edge
, ornode
. It turns out this feature is implemented inefficiently in V8 and copying properties over to a new object is around a 2x performance improvement. In addition, doing this manually instead of using the native implementation generates a lot less work for the garbage collector. You can see V8 bug 11536 for details. If the V8 performance bug is eventually fixed, the translation of this syntax will be disabled again for V8-based targets containing the bug fix.Fix object rest return value (#956)
This release fixes a bug where the value of an object rest assignment was incorrect if the object rest assignment was lowered:
Previously this code would incorrectly print
{y: 2}
(the value assigned toy
) when the object rest expression was lowered (i.e. with--target=es2017
or below). Now this code will correctly print{x: 1, y: 2}
instead. This bug did not affect code that did not rely on the return value of the assignment expression, such as this code:Basic support for CSS page margin rules (#955)
There are 16 different special at-rules that can be nested inside the
@page
rule. They are defined in this specification. Previously esbuild treated these as unknown rules, but with this release esbuild will now treat these as known rules. The only real difference in behavior is that esbuild will no longer warn about these rules being unknown.Add export name annotations to CommonJS output for node
When you import a CommonJS file using an ESM
import
statement in node, thedefault
import is the value ofmodule.exports
in the CommonJS file. In addition, node attempts to generate named exports for properties of themodule.exports
object.Except that node doesn't actually ever look at the properties of that object to determine the export names. Instead it parses the CommonJS file and scans the AST for certain syntax patterns. A full list of supported patterns can be found in the documentation for the
cjs-module-lexer
package. This library doesn't currently support the syntax patterns used by esbuild.While esbuild could adapt its syntax to these patterns, the patterns are less compact than the ones used by esbuild and doing this would lead to code bloat. Supporting two separate ways of generating export getters would also complicate esbuild's internal implementation, which is undesirable.
Another alternative could be to update the implementation of
cjs-module-lexer
to support the specific patterns used by esbuild. This is also undesirable because this pattern detection would break when minification is enabled, this would tightly couple esbuild's output format with node and prevent esbuild from changing it, and it wouldn't work for existing and previous versions of node that still have the old version of this library.Instead, esbuild will now add additional code to "annotate" ESM files that have been converted to CommonJS when esbuild's platform has been set to
node
. The annotation is dead code but is still detected by thecjs-module-lexer
library. If the original ESM file has the exportsfoo
andbar
, the additional annotation code will look like this:This allows you to use named imports with an ESM
import
statement in node (previously you could only use thedefault
import):v0.9.0
Compare Source
This release contains backwards-incompatible changes. Since esbuild is before version 1.0.0, these changes have been released as a new minor version to reflect this (as recommended by npm). You should either be pinning the exact version of
esbuild
in yourpackage.json
file or be using a version range syntax that only accepts patch upgrades such as^0.8.0
. See the documentation about semver for more information.Add support for node's
exports
field inpackage.json
files (#187)This feature was recently added to node. It allows you to rewrite what import paths inside your package map to as well as to prevent people from importing certain files in your package. Adding support for this to esbuild is a breaking change (i.e. code that was working fine before can easily stop working) so adding support for it has been delayed until this breaking change release.
One way to use this feature is to remap import paths for your package. For example, this would remap an import of
your-pkg/esm/lib.js
(the "public" import path) toyour-pkg/dist/esm/lib.js
(the "private" file system path):Another way to use this feature is to have conditional imports where the same import path can mean different things in different situations. For example, this would remap
require('your-pkg')
toyour-pkg/required.cjs
andimport 'your-pkg'
toyour-pkg/imported.mjs
:There is built-in support for the
import
andrequire
conditions depending on the kind of import and thebrowser
andnode
conditions depending on the current platform. In addition, thedefault
condition always applies regardless of the current configuration settings and can be used as a catch-all fallback condition.Note that when you use conditions, your package may end up in the bundle multiple times! This is a subtle issue that can cause bugs due to duplicate copies of your code's state in addition to bloating the resulting bundle. This is commonly known as the dual package hazard. The primary way of avoiding this is to put all of your code in the
require
condition and have theimport
condition just be a light wrapper that callsrequire
on your package and re-exports the package using ESM syntax.There is also support for custom conditions with the
--conditions=
flag. The meaning of these is entirely up to package authors. For example, you could imagine a package that requires you to configure--conditions=test,en-US
. Node has currently only endorsed thedevelopment
andproduction
custom conditions for recommended use.Remove the
esbuild.startService()
APIDue to #656, Calling
service.stop()
no longer does anything, so there is no longer a strong reason for keeping theesbuild.startService()
API around. The primary thing it currently does is just make the API more complicated and harder to use. You can now just callesbuild.build()
andesbuild.transform()
directly instead of callingesbuild.startService().then(service => service.build())
oresbuild.startService().then(service => service.transform())
.If you are using esbuild in the browser, you now need to call
esbuild.initialize({ wasmURL })
and wait for the returned promise before callingesbuild.transform()
. It takes the same options thatesbuild.startService()
used to take. Note that theesbuild.buildSync()
andesbuild.transformSync()
APIs still exist when using esbuild in node. Nothing has changed about the synchronous esbuild APIs.Remove the
metafile
fromoutputFiles
(#633)Previously using
metafile
with the API is unnecessarily cumbersome because you have to extract the JSON metadata from the output file yourself instead of it just being provided to you as a return value. This is especially a bummer if you are usingwrite: false
because then you need to use a for loop over the output files and do string comparisons with the file paths to try to find the one corresponding to themetafile
. Returning the metadata directly is an important UX improvement for the API. It means you can now do this:The banner and footer options are now language-specific (#712)
The
--banner=
and--footer=
options now require you to pass the file type:CLI:
JavaScript
Go
This was changed because the feature was originally added in a JavaScript-specific manner, which was an oversight. CSS banners and footers must be separate from JavaScript banners and footers to avoid injecting JavaScript syntax into your CSS files.
The extensions
.mjs
and.cjs
are no longer implicitPreviously the "resolve extensions" setting included
.mjs
and.cjs
but this is no longer the case. This wasn't a good default because it doesn't match node's behavior and could break some packages. You now have to either explicitly specify these extensions or configure the "resolve extensions" setting yourself.Remove the
--summary
flag and instead just always print a summary (#704)The summary can be disabled if you don't want it by passing
--log-level=warning
instead. And it can be enabled in the API by settinglogLevel: 'info'
. I'm going to try this because I believe it will improve the UX. People have this problem with esbuild when they first try it where it runs so quickly that they think it must be broken, only to later discover that it actually worked fine. While this is funny, it seems like a good indication that the UX could be improved. So I'm going to try automatically printing a summary to see how that goes. Note that the summary is not printed if incremental builds are active (this includes the watch and serve modes).Rename
--error-limit=
to--log-limit=
This parameter has been renamed because it now applies to both warnings and errors, not just to errors. Previously setting the error limit did not apply any limits to the number of warnings printed, which could sometimes result in a deluge of warnings that are problematic for Windows Command Prompt, which is very slow to print to and has very limited scrollback. Now the log limit applies to the total number of log messages including both errors and warnings, so no more than that number of messages will be printed. The log usually prints log messages immediately but it will now intentionally hold back warnings when approaching the limit to make room for possible future errors during a build. So if a build fails you should be guaranteed to see an error message (i.e. warnings can't use up the entire log limit and then prevent errors from being printed).
Remove the deprecated
--avoid-tdz
optionThis option is now always enabled and cannot be disabled, so it is being removed from the API. The existing API parameter no longer does anything so this removal has no effect the generated output.
Remove
SpinnerBusy
andSpinnerIdle
from the Go APIThese options were part of an experiment with the CLI that didn't work out. Watch mode no longer uses a spinner because it turns out people want to be able to interleave esbuild's stderr pipe with other tools and were getting tripped up by the spinner animation. These options no longer do anything and have been removed.
rickhanlonii/jest-silent-reporter
v0.5.0
Compare Source
#26
karma-runner/karma
v6.2.0
Compare Source
Features
6.1.2 (2021-03-09)
Bug Fixes
6.1.1 (2021-02-12)
Bug Fixes
v6.1.2
Compare Source
Bug Fixes
marvinhagemeister/karma-esbuild
v2.1.1
Compare Source
Bug Fixes
done
message (#23, thanks @jridgewell)Maintenance
karma-sourcemap-loader
(#24, thanks @jridgewell)realFile
usage (#21, thanks @jridgewell)v2.1.0
Compare Source
Features
Bug Fixes
Maintenance
Renovate configuration
📅 Schedule: "after 12am every weekday" in timezone America/Los_Angeles.
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻️ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by WhiteSource Renovate. View repository job log here.