-
Fix escaping of non-BMP characters in property names (#977)
Property names in object literals do not have to be quoted if the property is a valid JavaScript identifier. This is defined as starting with a character in the
ID_StartUnicode category and ending with zero or more characters in theID_ContinueUnicode category. However, esbuild had a bug where non-BMP characters (i.e. characters encoded using two UTF-16 code units instead of one) were always checked againstID_Continueinstead ofID_Startbecause they included a code unit that wasn't at the start. This could result in invalid JavaScript being generated when using--charset=utf8becauseID_Continueis a superset ofID_Startand contains some characters that are not valid at the start of an identifier. This bug has been fixed. -
Be maximally liberal in the interpretation of the
browserfield (#740)The
browserfield inpackage.jsonis an informal convention followed by browser-specific bundlers that allows package authors to substitute certain node-specific import paths with alternative browser-specific import paths. It doesn't have a rigorous specification and the canonical description of the feature doesn't include any tests. As a result, each bundler implements this feature differently. I have tried to create a survey of how different bundlers interpret thebrowserfield and the results are very inconsistent.This release attempts to change esbuild to support the union of the behavior of all other bundlers. That way if people have the
browserfield working with some other bundler and they switch to esbuild, thebrowserfield shouldn't ever suddenly stop working. This seemed like the most principled approach to take in this situation.The drawback of this approach is that it means the
browserfield may start working when switching to esbuild when it was previously not working. This could cause bugs, but I consider this to be a problem with the package (i.e. not using a more well-supported form of thebrowserfield), not a problem with esbuild itself.