/>;\r\n ```\r\n\r\nI think I originally didn't implement it even though it's part of the\r\n[JSX specification](https://facebook.github.io/jsx/) because it\r\npreviously didn't work in TypeScript (and potentially also in Babel?).\r\nHowever, support for it was [silently added in TypeScript\r\n4.8](https://togithub.com/microsoft/TypeScript/pull/47994) without me\r\nnoticing and Babel has also since fixed their [bugs regarding this\r\nfeature](https://togithub.com/babel/babel/pull/6006). So I'm adding it\r\nto esbuild too now that I know it's widely supported.\r\n\r\nKeep in mind that there is some ongoing discussion about [removing this\r\nfeature from JSX](https://togithub.com/facebook/jsx/issues/53). I agree\r\nthat the syntax seems out of place (it does away with the elegance of\r\n\"JSX is basically just XML with `{...}` escapes\" for something arguably\r\nharder to read, which doesn't seem like a good trade-off), but it's in\r\nthe specification and TypeScript and Babel both implement it so I'm\r\ngoing to have esbuild implement it too. However, I reserve the right to\r\nremove it from esbuild if it's ever removed from the specification in\r\nthe future. So use it with caution.\r\n\r\n- Fix a bug with TypeScript type parsing\r\n([#3574](https://togithub.com/evanw/esbuild/issues/3574))\r\n\r\nThis release fixes a bug with esbuild's TypeScript parser where a\r\nconditional type containing a union type that ends with an infer type\r\nthat ends with a constraint could fail to parse. This was caused by the\r\n\"don't parse a conditional type\" flag not getting passed through the\r\nunion type parser. Here's an example of valid TypeScript code that\r\npreviously failed to parse correctly:\r\n\r\n ```ts\r\ntype InferUnion
= T extends { a: infer U extends number } | infer U\r\nextends number ? U : never\r\n ```\r\n\r\n###\r\n[`v0.19.11`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01911)\r\n\r\n[Compare\r\nSource](https://togithub.com/evanw/esbuild/compare/v0.19.10...v0.19.11)\r\n\r\n- Fix TypeScript-specific class transform edge case\r\n([#3559](https://togithub.com/evanw/esbuild/issues/3559))\r\n\r\nThe previous release introduced an optimization that avoided\r\ntransforming `super()` in the class constructor for TypeScript code\r\ncompiled with `useDefineForClassFields` set to `false` if all class\r\ninstance fields have no initializers. The rationale was that in this\r\ncase, all class instance fields are omitted in the output so no changes\r\nto the constructor are needed. However, if all of this is the case *and*\r\nthere are `#private` instance fields with initializers, those private\r\ninstance field initializers were still being moved into the constructor.\r\nThis was problematic because they were being inserted before the call to\r\n`super()` (since `super()` is now no longer transformed in that case).\r\nThis release introduces an additional optimization that avoids moving\r\nthe private instance field initializers into the constructor in this\r\nedge case, which generates smaller code, matches the TypeScript\r\ncompiler's output more closely, and avoids this bug:\r\n\r\n ```ts\r\n // Original code\r\n class Foo extends Bar {\r\n #private = 1;\r\n public: any;\r\n constructor() {\r\n super();\r\n }\r\n }\r\n\r\n // Old output (with esbuild v0.19.9)\r\n class Foo extends Bar {\r\n constructor() {\r\n super();\r\n this.#private = 1;\r\n }\r\n #private;\r\n }\r\n\r\n // Old output (with esbuild v0.19.10)\r\n class Foo extends Bar {\r\n constructor() {\r\n this.#private = 1;\r\n super();\r\n }\r\n #private;\r\n }\r\n\r\n // New output\r\n class Foo extends Bar {\r\n #private = 1;\r\n constructor() {\r\n super();\r\n }\r\n }\r\n ```\r\n\r\n- Minifier: allow reording a primitive past a side-effect\r\n([#3568](https://togithub.com/evanw/esbuild/issues/3568))\r\n\r\nThe minifier previously allowed reordering a side-effect past a\r\nprimitive, but didn't handle the case of reordering a primitive past a\r\nside-effect. This additional case is now handled:\r\n\r\n ```js\r\n // Original code\r\n function f() {\r\n let x = false;\r\n let y = x;\r\n const boolean = y;\r\nlet frag = $.template(`hello\r\nworld
`);\r\n return frag;\r\n }\r\n\r\n // Old output (with --minify)\r\nfunction f(){const e=!1;return $.template(`hello world`)}\r\n\r\n // New output (with --minify)\r\nfunction f(){return $.template('hello\r\nworld
')}\r\n ```\r\n\r\n- Minifier: consider properties named using known `Symbol` instances to\r\nbe side-effect free\r\n([#3561](https://togithub.com/evanw/esbuild/issues/3561))\r\n\r\nMany things in JavaScript can have side effects including property\r\naccesses and ToString operations, so using a symbol such as\r\n`Symbol.iterator` as a computed property name is not obviously\r\nside-effect free. This release adds a special case for known `Symbol`\r\ninstances so that they are considered side-effect free when used as\r\nproperty names. For example, this class declaration will now be\r\nconsidered side-effect free:\r\n\r\n ```js\r\n class Foo {\r\n *[Symbol.iterator]() {\r\n }\r\n }\r\n ```\r\n\r\n- Provide the `stop()` API in node to exit esbuild's child process\r\n([#3558](https://togithub.com/evanw/esbuild/issues/3558))\r\n\r\nYou can now call `stop()` in esbuild's node API to exit esbuild's child\r\nprocess to reclaim the resources used. It only makes sense to do this\r\nfor a long-lived node process when you know you will no longer be making\r\nany more esbuild API calls. It is not necessary to call this to allow\r\nnode to exit, and it's advantageous to not call this in between calls to\r\nesbuild's API as sharing a single long-lived esbuild child process is\r\nmore efficient than re-creating a new esbuild child process for every\r\nAPI call. This API call used to exist but was removed in [version\r\n0.9.0](https://togithub.com/evanw/esbuild/releases/v0.9.0). This release\r\nadds it back due to a user request.\r\n\r\n###\r\n[`v0.19.10`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01910)\r\n\r\n[Compare\r\nSource](https://togithub.com/evanw/esbuild/compare/v0.19.9...v0.19.10)\r\n\r\n- Fix glob imports in TypeScript files\r\n([#3319](https://togithub.com/evanw/esbuild/issues/3319))\r\n\r\nThis release fixes a problem where bundling a TypeScript file containing\r\na glob import could emit a call to a helper function that doesn't exist.\r\nThe problem happened because esbuild's TypeScript transformation removes\r\nunused imports (which is required for correctness, as they may be\r\ntype-only imports) and esbuild's glob import transformation wasn't\r\ncorrectly marking the imported helper function as used. This wasn't\r\ncaught earlier because most of esbuild's glob import tests were written\r\nin JavaScript, not in TypeScript.\r\n\r\n- Fix `require()` glob imports with bundling disabled\r\n([#3546](https://togithub.com/evanw/esbuild/issues/3546))\r\n\r\nPreviously `require()` calls containing glob imports were incorrectly\r\ntransformed when bundling was disabled. All glob imports should only be\r\ntransformed when bundling is enabled. This bug has been fixed.\r\n\r\n- Fix a panic when transforming optional chaining with `define`\r\n([#3551](https://togithub.com/evanw/esbuild/issues/3551),\r\n[#3554](https://togithub.com/evanw/esbuild/pull/3554))\r\n\r\nThis release fixes a case where esbuild could crash with a panic, which\r\nwas triggered by using `define` to replace an expression containing an\r\noptional chain. Here is an example:\r\n\r\n ```js\r\n // Original code\r\n console.log(process?.env.SHELL)\r\n\r\n // Old output (with --define:process.env={})\r\n /* panic: Internal error (while parsing \"\") */\r\n\r\n // New output (with --define:process.env={})\r\n var define_process_env_default = {};\r\n console.log(define_process_env_default.SHELL);\r\n ```\r\n\r\nThis fix was contributed by\r\n[@hi-ogawa](https://togithub.com/hi-ogawa).\r\n\r\n- Work around a bug in node's CommonJS export name detector\r\n([#3544](https://togithub.com/evanw/esbuild/issues/3544))\r\n\r\nThe export names of a CommonJS module are dynamically-determined at run\r\ntime because CommonJS exports are properties on a mutable object. But\r\nthe export names of an ES module are statically-determined at module\r\ninstantiation time by using `import` and `export` syntax and cannot be\r\nchanged at run time.\r\n\r\nWhen you import a CommonJS module into an ES module in node, node scans\r\nover the source code to attempt to detect the set of export names that\r\nthe CommonJS module will end up using. That statically-determined set of\r\nnames is used as the set of names that the ES module is allowed to\r\nimport at module instantiation time. However, this scan appears to have\r\nbugs (or at least, can cause false positives) because it doesn't appear\r\nto do any scope analysis. Node will incorrectly consider the module to\r\nexport something even if the assignment is done to a local variable\r\ninstead of to the module-level `exports` object. For example:\r\n\r\n ```js\r\n // confuseNode.js\r\n exports.confuseNode = function(exports) {\r\n // If this local is called \"exports\", node incorrectly\r\n // thinks this file has an export called \"notAnExport\".\r\n exports.notAnExport = function() {\r\n };\r\n };\r\n ```\r\n\r\nYou can see that node incorrectly thinks the file `confuseNode.js` has\r\nan export called `notAnExport` when that file is loaded in an ES module\r\ncontext:\r\n\r\n ```console\r\n $ node -e 'import(\"./confuseNode.js\").then(console.log)'\r\n [Module: null prototype] {\r\n confuseNode: [Function (anonymous)],\r\n default: { confuseNode: [Function (anonymous)] },\r\n notAnExport: undefined\r\n }\r\n ```\r\n\r\nTo avoid this, esbuild will now rename local variables that use the\r\nnames `exports` and `module` when generating CommonJS output for the\r\n`node` platform.\r\n\r\n- Fix the return value of esbuild's `super()` shim\r\n([#3538](https://togithub.com/evanw/esbuild/issues/3538))\r\n\r\nSome people write `constructor` methods that use the return value of\r\n`super()` instead of using `this`. This isn't too common because\r\n[TypeScript doesn't let you do\r\nthat](https://togithub.com/microsoft/TypeScript/issues/37847) but it can\r\ncome up when writing JavaScript. Previously esbuild's class lowering\r\ntransform incorrectly transformed the return value of `super()` into\r\n`undefined`. With this release, the return value of `super()` will now\r\nbe `this` instead:\r\n\r\n ```js\r\n // Original code\r\n class Foo extends Object {\r\n field\r\n constructor() {\r\n console.log(typeof super())\r\n }\r\n }\r\n new Foo\r\n\r\n // Old output (with --target=es6)\r\n class Foo extends Object {\r\n constructor() {\r\n var __super = (...args) => {\r\n super(...args);\r\n __publicField(this, \"field\");\r\n };\r\n console.log(typeof __super());\r\n }\r\n }\r\n new Foo();\r\n\r\n // New output (with --target=es6)\r\n class Foo extends Object {\r\n constructor() {\r\n var __super = (...args) => {\r\n super(...args);\r\n __publicField(this, \"field\");\r\n return this;\r\n };\r\n console.log(typeof __super());\r\n }\r\n }\r\n new Foo();\r\n ```\r\n\r\n- Terminate the Go GC when esbuild's `stop()` API is called\r\n([#3552](https://togithub.com/evanw/esbuild/issues/3552))\r\n\r\nIf you use esbuild with WebAssembly and pass the `worker: false` flag to\r\n`esbuild.initialize()`, then esbuild will run the WebAssembly module on\r\nthe main thread. If you do this within a Deno test and that test calls\r\n`esbuild.stop()` to clean up esbuild's resources, Deno may complain that\r\na `setTimeout()` call lasted past the end of the test. This happens when\r\nthe Go is in the middle of a garbage collection pass and has scheduled\r\nadditional ongoing garbage collection work. Normally calling\r\n`esbuild.stop()` will terminate the web worker that the WebAssembly\r\nmodule runs in, which will terminate the Go GC, but that doesn't happen\r\nif you disable the web worker with `worker: false`.\r\n\r\nWith this release, esbuild will now attempt to terminate the Go GC in\r\nthis edge case by calling `clearTimeout()` on these pending timeouts.\r\n\r\n- Apply `/* @__NO_SIDE_EFFECTS__ */` on tagged template literals\r\n([#3511](https://togithub.com/evanw/esbuild/issues/3511))\r\n\r\nTagged template literals that reference functions annotated with a\r\n`@__NO_SIDE_EFFECTS__` comment are now able to be removed via\r\ntree-shaking if the result is unused. This is a convention from\r\n[Rollup](https://togithub.com/rollup/rollup/pull/5024). Here is an\r\nexample:\r\n\r\n ```js\r\n // Original code\r\nconst html = /* @__NO_SIDE_EFFECTS__ */ (a, ...b) => ({ a, b })\r\n html`remove`\r\n x = html`keep`\r\n\r\n // Old output (with --tree-shaking=true)\r\nconst html = /* @__NO_SIDE_EFFECTS__ */ (a, ...b) => ({ a, b });\r\n html`remove`;\r\n x = html`keep`;\r\n\r\n // New output (with --tree-shaking=true)\r\nconst html = /* @__NO_SIDE_EFFECTS__ */ (a, ...b) => ({ a, b });\r\n x = html`keep`;\r\n ```\r\n\r\nNote that this feature currently only works within a single file, so\r\nit's not especially useful. This feature does not yet work across\r\nseparate files. I still recommend using `@__PURE__` annotations instead\r\nof this feature, as they have wider tooling support. The drawback of\r\ncourse is that `@__PURE__` annotations need to be added at each call\r\nsite, not at the declaration, and for non-call expressions such as\r\ntemplate literals you need to wrap the expression in an IIFE\r\n(immediately-invoked function expression) to create a call expression to\r\napply the `@__PURE__` annotation to.\r\n\r\n- Publish builds for IBM AIX PowerPC 64-bit\r\n([#3549](https://togithub.com/evanw/esbuild/issues/3549))\r\n\r\nThis release publishes a binary executable to npm for IBM AIX PowerPC\r\n64-bit, which means that in theory esbuild can now be installed in that\r\nenvironment with `npm install esbuild`. This hasn't actually been tested\r\nyet. If you have access to such a system, it would be helpful to confirm\r\nwhether or not doing this actually works.\r\n\r\n###\r\n[`v0.19.9`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0199)\r\n\r\n[Compare\r\nSource](https://togithub.com/evanw/esbuild/compare/v0.19.8...v0.19.9)\r\n\r\n- Add support for transforming new CSS gradient syntax for older\r\nbrowsers\r\n\r\nThe specification called [CSS Images Module Level\r\n4](https://www.w3.org/TR/css-images-4/) introduces new CSS gradient\r\nsyntax for customizing how the browser interpolates colors in between\r\ncolor stops. You can now control the color space that the interpolation\r\nhappens in as well as (for \"polar\" color spaces) control whether hue\r\nangle interpolation happens clockwise or counterclockwise. You can read\r\nmore about this in [Mozilla's blog post about new CSS gradient\r\nfeatures](https://developer.mozilla.org/en-US/blog/css-color-module-level-4/).\r\n\r\nWith this release, esbuild will now automatically transform this syntax\r\nfor older browsers in the `target` list. For example, here's a gradient\r\nthat should appear as a rainbow in a browser that supports this new\r\nsyntax:\r\n\r\n ```css\r\n /* Original code */\r\n .rainbow-gradient {\r\n width: 100px;\r\n height: 100px;\r\nbackground: linear-gradient(in hsl longer hue, #7ff,\r\n#77f);\r\n }\r\n\r\n /* New output (with --target=chrome99) */\r\n .rainbow-gradient {\r\n width: 100px;\r\n height: 100px;\r\n background:\r\n linear-gradient(\r\n #77ffff,\r\n #77ffaa 12.5%,\r\n #77ff80 18.75%,\r\n #84ff77 21.88%,\r\n #99ff77 25%,\r\n #eeff77 37.5%,\r\n #fffb77 40.62%,\r\n #ffe577 43.75%,\r\n #ffbb77 50%,\r\n #ff9077 56.25%,\r\n #ff7b77 59.38%,\r\n #ff7788 62.5%,\r\n #ff77dd 75%,\r\n #ff77f2 78.12%,\r\n #f777ff 81.25%,\r\n #cc77ff 87.5%,\r\n #7777ff);\r\n }\r\n ```\r\n\r\nYou can now use this syntax in your CSS source code and esbuild will\r\nautomatically convert it to an equivalent gradient for older browsers.\r\nIn addition, esbuild will now also transform \"double position\" and\r\n\"transition hint\" syntax for older browsers as appropriate:\r\n\r\n ```css\r\n /* Original code */\r\n .stripes {\r\n width: 100px;\r\n height: 100px;\r\nbackground: linear-gradient(#e65 33%, #ff2 33% 67%, #99e 67%);\r\n }\r\n .glow {\r\n width: 100px;\r\n height: 100px;\r\n background: radial-gradient(white 10%, 20%, black);\r\n }\r\n\r\n /* New output (with --target=chrome33) */\r\n .stripes {\r\n width: 100px;\r\n height: 100px;\r\n background:\r\n linear-gradient(\r\n #e65 33%,\r\n #ff2 33%,\r\n #ff2 67%,\r\n #99e 67%);\r\n }\r\n .glow {\r\n width: 100px;\r\n height: 100px;\r\n background:\r\n radial-gradient(\r\n #ffffff 10%,\r\n #aaaaaa 12.81%,\r\n #959595 15.62%,\r\n #7b7b7b 21.25%,\r\n #5a5a5a 32.5%,\r\n #444444 43.75%,\r\n #323232 55%,\r\n #161616 77.5%,\r\n #000000);\r\n }\r\n ```\r\n\r\nYou can see visual examples of these new syntax features by looking at\r\n[esbuild's gradient transformation\r\ntests](https://esbuild.github.io/gradient-tests/).\r\n\r\nIf necessary, esbuild will construct a new gradient that approximates\r\nthe original gradient by recursively splitting the interval in between\r\ncolor stops until the approximation error is within a small threshold.\r\nThat is why the above output CSS contains many more color stops than the\r\ninput CSS.\r\n\r\nNote that esbuild deliberately *replaces* the original gradient with the\r\napproximation instead of inserting the approximation before the original\r\ngradient as a fallback. The latest version of Firefox has multiple\r\ngradient rendering bugs (including incorrect interpolation of\r\npartially-transparent colors and interpolating non-sRGB colors using the\r\nincorrect color space). If esbuild didn't replace the original gradient,\r\nthen Firefox would use the original gradient instead of the fallback the\r\nappearance would be incorrect in Firefox. In other words, the latest\r\nversion of Firefox supports modern gradient syntax but interprets it\r\nincorrectly.\r\n\r\n- Add support for `color()`, `lab()`, `lch()`, `oklab()`, `oklch()`, and\r\n`hwb()` in CSS\r\n\r\nCSS has recently added lots of new ways of specifying colors. You can\r\nread more about this in [Chrome's blog post about CSS color\r\nspaces](https://developer.chrome.com/docs/css-ui/high-definition-css-color-guide).\r\n\r\nThis release adds support for minifying colors that use the `color()`,\r\n`lab()`, `lch()`, `oklab()`, `oklch()`, or `hwb()` syntax and/or\r\ntransforming these colors for browsers that don't support it yet:\r\n\r\n ```css\r\n /* Original code */\r\n div {\r\n color: hwb(90deg 20% 40%);\r\n background: color(display-p3 1 0 0);\r\n }\r\n\r\n /* New output (with --target=chrome99) */\r\n div {\r\n color: #669933;\r\n background: #ff0f0e;\r\n background: color(display-p3 1 0 0);\r\n }\r\n ```\r\n\r\nAs you can see, colors outside of the sRGB color space such as\r\n`color(display-p3 1 0 0)` are mapped back into the sRGB gamut and\r\ninserted as a fallback for browsers that don't support the new color\r\nsyntax.\r\n\r\n- Allow empty type parameter lists in certain cases\r\n([#3512](https://togithub.com/evanw/esbuild/issues/3512))\r\n\r\nTypeScript allows interface declarations and type aliases to have empty\r\ntype parameter lists. Previously esbuild didn't handle this edge case\r\nbut with this release, esbuild will now parse this syntax:\r\n\r\n ```ts\r\n interface Foo<> {}\r\n type Bar<> = {}\r\n ```\r\n\r\nThis fix was contributed by\r\n[@magic-akari](https://togithub.com/magic-akari).\r\n\r\n###\r\n[`v0.19.8`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0198)\r\n\r\n[Compare\r\nSource](https://togithub.com/evanw/esbuild/compare/v0.19.7...v0.19.8)\r\n\r\n- Add a treemap chart to esbuild's bundle analyzer\r\n([#2848](https://togithub.com/evanw/esbuild/issues/2848))\r\n\r\nThe bundler analyzer on esbuild's website\r\n(https://esbuild.github.io/analyze/) now has a treemap chart type in\r\naddition to the two existing chart types (sunburst and flame). This\r\nshould be more familiar for people coming from other similar tools, as\r\nwell as make better use of large screens.\r\n\r\n- Allow decorators after the `export` keyword\r\n([#104](https://togithub.com/evanw/esbuild/issues/104))\r\n\r\nPreviously esbuild's decorator parser followed the original behavior of\r\nTypeScript's experimental decorators feature, which only allowed\r\ndecorators to come before the `export` keyword. However, the upcoming\r\nJavaScript decorators feature also allows decorators to come after the\r\n`export` keyword. And with TypeScript 5.0, TypeScript now also allows\r\nexperimental decorators to come after the `export` keyword too. So\r\nesbuild now allows this as well:\r\n\r\n ```js\r\n // This old syntax has always been permitted:\r\n @decorator export class Foo {}\r\n @decorator export default class Foo {}\r\n\r\n // This new syntax is now permitted too:\r\n export @decorator class Foo {}\r\n export default @decorator class Foo {}\r\n ```\r\n\r\nIn addition, esbuild's decorator parser has been rewritten to fix\r\nseveral subtle and likely unimportant edge cases with esbuild's parsing\r\nof exports and decorators in TypeScript (e.g. TypeScript apparently does\r\nautomatic semicolon insertion after `interface` and `export interface`\r\nbut not after `export default interface`).\r\n\r\n- Pretty-print decorators using the same whitespace as the original\r\n\r\nWhen printing code containing decorators, esbuild will now try to\r\nrespect whether the original code contained newlines after the decorator\r\nor not. This can make generated code containing many decorators much\r\nmore compact to read:\r\n\r\n ```js\r\n // Original code\r\n class Foo {\r\n @a @b @c abc\r\n @x @y @z xyz\r\n }\r\n\r\n // Old output\r\n class Foo {\r\n @a\r\n @b\r\n @c\r\n abc;\r\n @x\r\n @y\r\n @z\r\n xyz;\r\n }\r\n\r\n // New output\r\n class Foo {\r\n @a @b @c abc;\r\n @x @y @z xyz;\r\n }\r\n ```\r\n\r\n###\r\n[`v0.19.7`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0197)\r\n\r\n[Compare\r\nSource](https://togithub.com/evanw/esbuild/compare/v0.19.6...v0.19.7)\r\n\r\n- Add support for bundling code that uses import attributes\r\n([#3384](https://togithub.com/evanw/esbuild/issues/3384))\r\n\r\nJavaScript is gaining new syntax for associating a map of string\r\nkey-value pairs with individual ESM imports. The proposal is still a\r\nwork in progress and is still undergoing significant changes before\r\nbeing finalized. However, the first iteration has already been shipping\r\nin Chromium-based browsers for a while, and the second iteration has\r\nlanded in V8 and is now shipping in node, so it makes sense for esbuild\r\nto support it. Here are the two major iterations of this proposal (so\r\nfar):\r\n\r\n 1. Import assertions (deprecated, will not be standardized)\r\n - Uses the `assert` keyword\r\n - Does *not* affect module resolution\r\n - Causes an error if the assertion fails\r\n - Shipping in Chrome 91+ (and in esbuild 0.11.22+)\r\n\r\n 2. Import attributes (currently set to become standardized)\r\n - Uses the `with` keyword\r\n - Affects module resolution\r\n - Unknown attributes cause an error\r\n - Shipping in node 21+\r\n\r\nYou can already use esbuild to bundle code that uses import assertions\r\n(the first iteration). However, this feature is mostly useless for\r\nbundlers because import assertions are not allowed to affect module\r\nresolution. It's basically only useful as an annotation on external\r\nimports, which esbuild will then preserve in the output for use in a\r\nbrowser (which would otherwise refuse to load certain imports).\r\n\r\nWith this release, esbuild now supports bundling code that uses import\r\nattributes (the second iteration). This is much more useful for bundlers\r\nbecause they are allowed to affect module resolution, which means the\r\nkey-value pairs can be provided to plugins. Here's an example, which\r\nuses esbuild's built-in support for the upcoming [JSON module\r\nstandard](https://togithub.com/tc39/proposal-json-modules):\r\n\r\n ```js\r\n // On static imports\r\n import foo from './package.json' with { type: 'json' }\r\n console.log(foo)\r\n\r\n // On dynamic imports\r\nconst bar = await import('./package.json', { with: { type: 'json' } })\r\n console.log(bar)\r\n ```\r\n\r\nOne important consequence of the change in semantics between import\r\nassertions and import attributes is that two imports with identical\r\npaths but different import attributes are now considered to be different\r\nmodules. This is because the import attributes are provided to the\r\nloader, which might then use those attributes during loading. For\r\nexample, you could imagine an image loader that produces an image of a\r\ndifferent size depending on the import attributes.\r\n\r\nImport attributes are now reported in the\r\n[metafile](https://esbuild.github.io/api/#metafile) and are now provided\r\nto [on-load plugins](https://esbuild.github.io/plugins/#on-load) as a\r\nmap in the `with` property. For example, here's an esbuild plugin that\r\nturns all imports with a `type` import attribute equal to `'cheese'`\r\ninto a module that exports the cheese emoji:\r\n\r\n ```js\r\n const cheesePlugin = {\r\n name: 'cheese',\r\n setup(build) {\r\n build.onLoad({ filter: /.*/ }, args => {\r\n if (args.with.type === 'cheese') return {\r\n contents: `export default \"๐ง\"`,\r\n }\r\n })\r\n }\r\n }\r\n\r\n require('esbuild').build({\r\n bundle: true,\r\n write: false,\r\n stdin: {\r\n contents: `\r\nimport foo from 'data:text/javascript,' with { type: 'cheese' }\r\n console.log(foo)\r\n `,\r\n },\r\n plugins: [cheesePlugin],\r\n }).then(result => {\r\n const code = new Function(result.outputFiles[0].text)\r\n code()\r\n })\r\n ```\r\n\r\nWarning: It's possible that the second iteration of this feature may\r\nchange significantly again even though it's already shipping in real\r\nJavaScript VMs (since it has already happened once before). In that\r\ncase, esbuild may end up adjusting its implementation to match the\r\neventual standard behavior. So keep in mind that by using this, you are\r\nusing an unstable upcoming JavaScript feature that may undergo breaking\r\nchanges in the future.\r\n\r\n- Adjust TypeScript experimental decorator behavior\r\n([#3230](https://togithub.com/evanw/esbuild/issues/3230),\r\n[#3326](https://togithub.com/evanw/esbuild/issues/3326),\r\n[#3394](https://togithub.com/evanw/esbuild/issues/3394))\r\n\r\nWith this release, esbuild will now allow TypeScript experimental\r\ndecorators to access both static class properties and `#private` class\r\nnames. For example:\r\n\r\n ```js\r\n const check =\r\n (a: T, b: T): PropertyDecorator =>\r\n () => console.log(a === b)\r\n\r\n async function test() {\r\n class Foo {\r\n static #foo = 1\r\n static bar = 1 + Foo.#foo\r\n @check(Foo.#foo, 1) a: any\r\n @check(Foo.bar, await Promise.resolve(2)) b: any\r\n }\r\n }\r\n\r\n test().then(() => console.log('pass'))\r\n ```\r\n\r\nThis will now print `true true pass` when compiled by esbuild.\r\nPreviously esbuild evaluated TypeScript decorators outside of the class\r\nbody, so it didn't allow decorators to access `Foo` or `#foo`. Now\r\nesbuild does something different, although it's hard to concisely\r\nexplain exactly what esbuild is doing now (see the background section\r\nbelow for more information).\r\n\r\nNote that TypeScript's experimental decorator support is currently\r\nbuggy: TypeScript's compiler passes this test if only the first `@check`\r\nis present or if only the second `@check` is present, but TypeScript's\r\ncompiler fails this test if both checks are present together. I haven't\r\nchanged esbuild to match TypeScript's behavior exactly here because I'm\r\nwaiting for TypeScript to fix these bugs instead.\r\n\r\nSome background: TypeScript experimental decorators don't have\r\nconsistent semantics regarding the context that the decorators are\r\nevaluated in. For example, TypeScript will let you use `await` within a\r\ndecorator, which implies that the decorator runs outside the class body\r\n(since `await` isn't supported inside a class body), but TypeScript will\r\nalso let you use `#private` names, which implies that the decorator runs\r\ninside the class body (since `#private` names are only supported inside\r\na class body). The value of `this` in a decorator is also buggy (the\r\nrun-time value of `this` changes if any decorator in the class uses a\r\n`#private` name but the type of `this` doesn't change, leading to the\r\ntype checker no longer matching reality). These inconsistent semantics\r\nmake it hard for esbuild to implement this feature as decorator\r\nevaluation happens in some superposition of both inside and outside the\r\nclass body that is particular to the internal implementation details of\r\nthe TypeScript compiler.\r\n\r\n- Forbid `--keep-names` when targeting old browsers\r\n([#3477](https://togithub.com/evanw/esbuild/issues/3477))\r\n\r\nThe `--keep-names` setting needs to be able to assign to the `name`\r\nproperty on functions and classes. However, before ES6 this property was\r\nnon-configurable, and attempting to assign to it would throw an error.\r\nSo with this release, esbuild will no longer allow you to enable this\r\nsetting while also targeting a really old browser.\r\n\r\n###\r\n[`v0.19.6`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0196)\r\n\r\n[Compare\r\nSource](https://togithub.com/evanw/esbuild/compare/v0.19.5...v0.19.6)\r\n\r\n- Fix a constant folding bug with bigint equality\r\n\r\nThis release fixes a bug where esbuild incorrectly checked for bigint\r\nequality by checking the equality of the bigint literal text. This is\r\ncorrect if the bigint doesn't have a radix because bigint literals\r\nwithout a radix are always in canonical form (since leading zeros are\r\nnot allowed). However, this is incorrect if the bigint has a radix (e.g.\r\n`0x123n`) because the canonical form is not enforced when a radix is\r\npresent.\r\n\r\n ```js\r\n // Original code\r\n console.log(!!0n, !!1n, 123n === 123n)\r\n console.log(!!0x0n, !!0x1n, 123n === 0x7Bn)\r\n\r\n // Old output\r\n console.log(false, true, true);\r\n console.log(true, true, false);\r\n\r\n // New output\r\n console.log(false, true, true);\r\n console.log(!!0x0n, !!0x1n, 123n === 0x7Bn);\r\n ```\r\n\r\n- Add some improvements to the JavaScript minifier\r\n\r\nThis release adds more cases to the JavaScript minifier, including\r\nsupport for inlining `String.fromCharCode` and\r\n`String.prototype.charCodeAt` when possible:\r\n\r\n ```js\r\n // Original code\r\ndocument.onkeydown = e => e.keyCode === 'A'.charCodeAt(0) &&\r\nconsole.log(String.fromCharCode(55358, 56768))\r\n\r\n // Old output (with --minify)\r\n\r\ndocument.onkeydown=o=>o.keyCode===\"A\".charCodeAt(0)&&console.log(String.fromCharCode(55358,56768));\r\n\r\n // New output (with --minify)\r\n document.onkeydown=o=>o.keyCode===65&&console.log(\"๐ง\");\r\n ```\r\n\r\nIn addition, immediately-invoked function expressions (IIFEs) that\r\nreturn a single expression are now inlined when minifying. This makes it\r\npossible to use IIFEs in combination with `@__PURE__` annotations to\r\nannotate arbitrary expressions as side-effect free without the IIFE\r\nwrapper impacting code size. For example:\r\n\r\n ```js\r\n // Original code\r\nconst sideEffectFreeOffset = /* @__PURE__ */ (() =>\r\ncomputeSomething())()\r\n use(sideEffectFreeOffset)\r\n\r\n // Old output (with --minify)\r\n const e=(()=>computeSomething())();use(e);\r\n\r\n // New output (with --minify)\r\n const e=computeSomething();use(e);\r\n ```\r\n\r\n- Automatically prefix the `mask-composite` CSS property for WebKit\r\n([#3493](https://togithub.com/evanw/esbuild/issues/3493))\r\n\r\nThe `mask-composite` property will now be prefixed as\r\n`-webkit-mask-composite` for older WebKit-based browsers. In addition to\r\nprefixing the property name, handling older browsers also requires\r\nrewriting the values since WebKit uses non-standard names for the mask\r\ncomposite modes:\r\n\r\n ```css\r\n /* Original code */\r\n div {\r\n mask-composite: add, subtract, intersect, exclude;\r\n }\r\n\r\n /* New output (with --target=chrome100) */\r\n div {\r\n -webkit-mask-composite:\r\n source-over,\r\n source-out,\r\n source-in,\r\n xor;\r\n mask-composite:\r\n add,\r\n subtract,\r\n intersect,\r\n exclude;\r\n }\r\n ```\r\n\r\n- Avoid referencing `this` from JSX elements in derived class\r\nconstructors\r\n([#3454](https://togithub.com/evanw/esbuild/issues/3454))\r\n\r\nWhen you enable `--jsx=automatic` and `--jsx-dev`, the JSX transform is\r\nsupposed to insert `this` as the last argument to the `jsxDEV` function.\r\nI'm not sure exactly why this is and I can't find any specification for\r\nit, but in any case this causes the generated code to crash when you use\r\na JSX element in a derived class constructor before the call to\r\n`super()` as `this` is not allowed to be accessed at that point. For\r\nexample\r\n\r\n ```js\r\n // Original code\r\n class ChildComponent extends ParentComponent {\r\n constructor() {\r\n super()\r\n }\r\n }\r\n\r\n // Problematic output (with --loader=jsx --jsx=automatic --jsx-dev)\r\n import { jsxDEV } from \"react/jsx-dev-runtime\";\r\n class ChildComponent extends ParentComponent {\r\n constructor() {\r\n super(/* @__PURE__ */ jsxDEV(\"div\", {}, void 0, false, {\r\n fileName: \"\",\r\n lineNumber: 3,\r\n columnNumber: 15\r\n }, this)); // The reference to \"this\" crashes here\r\n }\r\n }\r\n ```\r\n\r\nThe TypeScript compiler doesn't handle this at all while the Babel\r\ncompiler just omits `this` for the entire constructor (even after the\r\ncall to `super()`). There seems to be no specification so I can't be\r\nsure that this change doesn't break anything important. But given that\r\nBabel is pretty loose with this and TypeScript doesn't handle this at\r\nall, I'm guessing this value isn't too important. React's blog post\r\nseems to indicate that this value was intended to be used for a\r\nReact-specific migration warning at some point, so it could even be that\r\nthis value is irrelevant now. Anyway the crash in this case should now\r\nbe fixed.\r\n\r\n- Allow package subpath imports to map to node built-ins\r\n([#3485](https://togithub.com/evanw/esbuild/issues/3485))\r\n\r\nYou are now able to use a [subpath\r\nimport](https://nodejs.org/api/packages.html#subpath-imports) in your\r\npackage to resolve to a node built-in module. For example, with a\r\n`package.json` file like this:\r\n\r\n ```json\r\n {\r\n \"type\": \"module\",\r\n \"imports\": {\r\n \"#stream\": {\r\n \"node\": \"stream\",\r\n \"default\": \"./stub.js\"\r\n }\r\n }\r\n }\r\n ```\r\n\r\n You can now import from node's `stream` module like this:\r\n\r\n ```js\r\n import * as stream from '#stream';\r\n console.log(Object.keys(stream));\r\n ```\r\n\r\nThis will import from node's `stream` module when the platform is `node`\r\nand from `./stub.js` otherwise.\r\n\r\n- No longer throw an error when a `Symbol` is missing\r\n([#3453](https://togithub.com/evanw/esbuild/issues/3453))\r\n\r\nCertain JavaScript syntax features use special properties on the global\r\n`Symbol` object. For example, the asynchronous iteration syntax uses\r\n`Symbol.asyncIterator`. Previously esbuild's generated code for older\r\nbrowsers required this symbol to be polyfilled. However, starting with\r\nthis release esbuild will use\r\n[`Symbol.for()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/for)\r\nto construct these symbols if they are missing instead of throwing an\r\nerror about a missing polyfill. This means your code no longer needs to\r\ninclude a polyfill for missing symbols as long as your code also uses\r\n`Symbol.for()` for missing symbols.\r\n\r\n- Parse upcoming changes to TypeScript syntax\r\n([#3490](https://togithub.com/evanw/esbuild/issues/3490),\r\n[#3491](https://togithub.com/evanw/esbuild/pull/3491))\r\n\r\nWith this release, you can now use `from` as the name of a default\r\ntype-only import in TypeScript code, as well as `of` as the name of an\r\n`await using` loop iteration variable:\r\n\r\n ```ts\r\n import type from from 'from'\r\n for (await using of of of) ;\r\n ```\r\n\r\nThis matches similar changes in the TypeScript compiler\r\n([#56376](https://togithub.com/microsoft/TypeScript/issues/56376)\r\nand\r\n[#55555](https://togithub.com/microsoft/TypeScript/issues/55555))\r\nwhich will start allowing this syntax in an upcoming version of\r\nTypeScript. Please never actually write code like this.\r\n\r\nThe type-only import syntax change was contributed by\r\n[@magic-akari](https://togithub.com/magic-akari).\r\n\r\n###\r\n[`v0.19.5`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0195)\r\n\r\n[Compare\r\nSource](https://togithub.com/evanw/esbuild/compare/v0.19.4...v0.19.5)\r\n\r\n- Fix a regression in 0.19.0 regarding `paths` in `tsconfig.json`\r\n([#3354](https://togithub.com/evanw/esbuild/issues/3354))\r\n\r\nThe fix in esbuild version 0.19.0 to process `tsconfig.json` aliases\r\nbefore the `--packages=external` setting unintentionally broke an edge\r\ncase in esbuild's handling of certain `tsconfig.json` aliases where\r\nthere are multiple files with the same name in different directories.\r\nThis release adjusts esbuild's behavior for this edge case so that it\r\npasses while still processing aliases before `--packages=external`.\r\nPlease read the linked issue for more details.\r\n\r\n- Fix a CSS `font` property minification bug\r\n([#3452](https://togithub.com/evanw/esbuild/issues/3452))\r\n\r\nThis release fixes a bug where esbuild's CSS minifier didn't insert a\r\nspace between the font size and the font family in the `font` CSS\r\nshorthand property in the edge case where the original source code\r\ndidn't already have a space and the leading string token was shortened\r\nto an identifier:\r\n\r\n ```css\r\n /* Original code */\r\n .foo { font: 16px\"Menlo\"; }\r\n\r\n /* Old output (with --minify) */\r\n .foo{font:16pxMenlo}\r\n\r\n /* New output (with --minify) */\r\n .foo{font:16px Menlo}\r\n ```\r\n\r\n- Fix bundling CSS with asset names containing spaces\r\n([#3410](https://togithub.com/evanw/esbuild/issues/3410))\r\n\r\nAssets referenced via CSS `url()` tokens may cause esbuild to generate\r\ninvalid output when bundling if the file name contains spaces (e.g.\r\n`url(image 2.png)`). With this release, esbuild will now quote all\r\nbundled asset references in `url()` tokens to avoid this problem. This\r\nonly affects assets loaded using the `file` and `copy` loaders.\r\n\r\n- Fix invalid CSS `url()` tokens in `@import` rules\r\n([#3426](https://togithub.com/evanw/esbuild/issues/3426))\r\n\r\nIn the future, CSS `url()` tokens may contain additional stuff after the\r\nURL. This is irrelevant today as no CSS specification does this. But\r\nesbuild previously had a bug where using these tokens in an `@import`\r\nrule resulted in malformed output. This bug has been fixed.\r\n\r\n- Fix `browser` + `false` + `type: module` in `package.json`\r\n([#3367](https://togithub.com/evanw/esbuild/issues/3367))\r\n\r\nThe `browser` field in `package.json` allows you to map a file to\r\n`false` to have it be treated as an empty file when bundling for the\r\nbrowser. However, if `package.json` contains `\"type\": \"module\"` then all\r\n`.js` files will be considered ESM, not CommonJS. Importing a named\r\nimport from an empty CommonJS file gives you undefined, but importing a\r\nnamed export from an empty ESM file is a build error. This release\r\nchanges esbuild's interpretation of these files mapped to `false` in\r\nthis situation from ESM to CommonJS to avoid generating build errors for\r\nnamed imports.\r\n\r\n- Fix a bug in top-level await error reporting\r\n([#3400](https://togithub.com/evanw/esbuild/issues/3400))\r\n\r\nUsing `require()` on a file that contains [top-level\r\nawait](https://v8.dev/features/top-level-await) is not allowed because\r\n`require()` must return synchronously and top-level await makes that\r\nimpossible. You will get a build error if you try to bundle code that\r\ndoes this with esbuild. This release fixes a bug in esbuild's error\r\nreporting code for complex cases of this situation involving multiple\r\nlevels of imports to get to the module containing the top-level await.\r\n\r\n- Update to Unicode 15.1.0\r\n\r\nThe character tables that determine which characters form valid\r\nJavaScript identifiers have been updated from Unicode version 15.0.0 to\r\nthe newly-released Unicode version 15.1.0. I'm not putting an example in\r\nthe release notes because all of the new chara\r\n\r\n\r\n\r\n---\r\n\r\n### Configuration\r\n\r\n๐
**Schedule**: Branch creation - \"before 9am on monday\" (UTC),\r\nAutomerge - At any time (no schedule defined).\r\n\r\n๐ฆ **Automerge**: Disabled by config. Please merge this manually once you\r\nare satisfied.\r\n\r\nโป **Rebasing**: Whenever PR becomes conflicted, or you tick the\r\nrebase/retry checkbox.\r\n\r\n๐ป **Immortal**: This PR will be recreated if closed unmerged. Get\r\n[config help](https://togithub.com/renovatebot/renovate/discussions) if\r\nthat's undesired.\r\n\r\n---\r\n\r\n- [ ] If you want to rebase/retry this PR, check\r\nthis box\r\n\r\n---\r\n\r\nThis PR has been generated by [Mend\r\nRenovate](https://www.mend.io/free-developer-tools/renovate/). View\r\nrepository job log\r\n[here](https://developer.mend.io/github/keithamus/hdx).\r\n\r\n\r\n\r\nCo-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>","shortMessageHtmlLink":"Update dependencies (#19)"}},{"before":null,"after":"db8b4ae6f283929e86c5e6adc7de8d3e1c54f61b","ref":"refs/heads/renovate/dependencies","pushedAt":"2024-05-06T21:29:28.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"renovate[bot]","name":null,"path":"/apps/renovate","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/2740?s=80&v=4"},"commit":{"message":"Update dependencies","shortMessageHtmlLink":"Update dependencies"}},{"before":"e32a20a97edeee4cbebc3f4ab2f10c2d2722ac2b","after":null,"ref":"refs/heads/renovate/postcss-import-16.x","pushedAt":"2024-05-06T21:25:38.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"keithamus","name":"Keith Cirkel","path":"/keithamus","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/118266?s=80&v=4"}},{"before":"82cc0ae3f9b144f9120e744b79686cbd0c44c23b","after":"2dea75dea2d2da0f74d609247966ffe1ddfc12e1","ref":"refs/heads/main","pushedAt":"2024-05-06T21:25:37.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"keithamus","name":"Keith Cirkel","path":"/keithamus","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/118266?s=80&v=4"},"commit":{"message":"Update dependency postcss-import to v16 (#18)\n\n[](https://renovatebot.com)\r\n\r\nThis PR contains the following updates:\r\n\r\n| Package | Change | Age | Adoption | Passing | Confidence |\r\n|---|---|---|---|---|---|\r\n| [postcss-import](https://togithub.com/postcss/postcss-import) |\r\n[`^15.1.0` ->\r\n`^16.0.0`](https://renovatebot.com/diffs/npm/postcss-import/15.1.0/16.1.0)\r\n|\r\n[](https://docs.renovatebot.com/merge-confidence/)\r\n|\r\n[](https://docs.renovatebot.com/merge-confidence/)\r\n|\r\n[](https://docs.renovatebot.com/merge-confidence/)\r\n|\r\n[](https://docs.renovatebot.com/merge-confidence/)\r\n|\r\n\r\n---\r\n\r\n### Release Notes\r\n\r\n\r\npostcss/postcss-import (postcss-import)
\r\n\r\n###\r\n[`v16.1.0`](https://togithub.com/postcss/postcss-import/blob/HEAD/CHANGELOG.md#1610--2024-03-20)\r\n\r\n[Compare\r\nSource](https://togithub.com/postcss/postcss-import/compare/16.0.1...16.1.0)\r\n\r\n- Allow bundling URLs with fragments (useful for Vite users)\r\n([#560](https://togithub.com/postcss/postcss-import/issues/560),\r\n[#561](https://togithub.com/postcss/postcss-import/pull/561))\r\n\r\n###\r\n[`v16.0.1`](https://togithub.com/postcss/postcss-import/blob/HEAD/CHANGELOG.md#1601--2024-02-14)\r\n\r\n[Compare\r\nSource](https://togithub.com/postcss/postcss-import/compare/16.0.0...16.0.1)\r\n\r\n- Fix crash when handling some `@import`s with media conditions\r\n([#557](https://togithub.com/postcss/postcss-import/issues/557),\r\n[#558](https://togithub.com/postcss/postcss-import/pull/558))\r\n\r\n###\r\n[`v16.0.0`](https://togithub.com/postcss/postcss-import/blob/HEAD/CHANGELOG.md#1600--2024-01-02)\r\n\r\n[Compare\r\nSource](https://togithub.com/postcss/postcss-import/compare/15.1.0...16.0.0)\r\n\r\n- **BREAKING:** Require Node.js v18+\r\n([#550](https://togithub.com/postcss/postcss-import/issues/550),\r\n[#551](https://togithub.com/postcss/postcss-import/pull/551))\r\n- **BREAKING:** Signifigant rewrite, with small behavioral tweaks in a\r\nnumber of edge cases\r\n- Support for `@supports` conditional imports added\r\n([#532](https://togithub.com/postcss/postcss-import/issues/532),\r\n[#548](https://togithub.com/postcss/postcss-import/pull/548))\r\n- When `skipDuplicates` is `false`, handles import cycles correctly\r\n([#462](https://togithub.com/postcss/postcss-import/issues/462),\r\n[#535](https://togithub.com/postcss/postcss-import/pull/535))\r\n- Add `warnOnEmpty` option to allow disabling warnings for empty files\r\n([#84](https://togithub.com/postcss/postcss-import/issues/84),\r\n[#541](https://togithub.com/postcss/postcss-import/pull/541))\r\n- Use proper `node.error`s\r\n([#518](https://togithub.com/postcss/postcss-import/issues/518),\r\n[#540](https://togithub.com/postcss/postcss-import/pull/540))\r\n\r\nHuge thanks to [`@romainmenke`](https://togithub.com/romainmenke) for\r\nall the hard work he put into this release.\r\n\r\n \r\n\r\n---\r\n\r\n### Configuration\r\n\r\n๐
**Schedule**: Branch creation - At any time (no schedule defined),\r\nAutomerge - At any time (no schedule defined).\r\n\r\n๐ฆ **Automerge**: Disabled by config. Please merge this manually once you\r\nare satisfied.\r\n\r\nโป **Rebasing**: Whenever PR becomes conflicted, or you tick the\r\nrebase/retry checkbox.\r\n\r\n๐ **Ignore**: Close this PR and you won't be reminded about this update\r\nagain.\r\n\r\n---\r\n\r\n- [ ] If you want to rebase/retry this PR, check\r\nthis box\r\n\r\n---\r\n\r\nThis PR has been generated by [Mend\r\nRenovate](https://www.mend.io/free-developer-tools/renovate/). View\r\nrepository job log\r\n[here](https://developer.mend.io/github/keithamus/hdx).\r\n\r\n\r\n\r\nCo-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>","shortMessageHtmlLink":"Update dependency postcss-import to v16 (#18)"}},{"before":"d5261d24350eaa832f9f7e92a4b56d431ba0d283","after":null,"ref":"refs/heads/renovate/cssnano-7.x","pushedAt":"2024-05-06T19:02:31.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"keithamus","name":"Keith Cirkel","path":"/keithamus","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/118266?s=80&v=4"}},{"before":"c65db45cf2d446bbbb64e0fdbb3dbfdef665d8f4","after":"82cc0ae3f9b144f9120e744b79686cbd0c44c23b","ref":"refs/heads/main","pushedAt":"2024-05-06T19:02:30.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"keithamus","name":"Keith Cirkel","path":"/keithamus","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/118266?s=80&v=4"},"commit":{"message":"Update dependency cssnano to v7 (#17)\n\n[](https://renovatebot.com)\r\n\r\nThis PR contains the following updates:\r\n\r\n| Package | Change | Age | Adoption | Passing | Confidence |\r\n|---|---|---|---|---|---|\r\n| [cssnano](https://togithub.com/cssnano/cssnano) | [`^6.0.1` ->\r\n`^7.0.0`](https://renovatebot.com/diffs/npm/cssnano/6.1.2/7.0.1) |\r\n[](https://docs.renovatebot.com/merge-confidence/)\r\n|\r\n[](https://docs.renovatebot.com/merge-confidence/)\r\n|\r\n[](https://docs.renovatebot.com/merge-confidence/)\r\n|\r\n[](https://docs.renovatebot.com/merge-confidence/)\r\n|\r\n\r\n---\r\n\r\n### Release Notes\r\n\r\n\r\ncssnano/cssnano (cssnano)
\r\n\r\n###\r\n[`v7.0.1`](https://togithub.com/cssnano/cssnano/releases/tag/cssnano%407.0.1):\r\nv7.0.1\r\n\r\n[Compare\r\nSource](https://togithub.com/cssnano/cssnano/compare/cssnano@7.0.0...cssnano@7.0.1)\r\n\r\n#### Patch changes\r\n\r\nUpdate postcss-calc dependency to latest version\r\n\r\n###\r\n[`v7.0.0`](https://togithub.com/cssnano/cssnano/releases/tag/cssnano%407.0.0):\r\nv7.0.0\r\n\r\n[Compare\r\nSource](https://togithub.com/cssnano/cssnano/compare/cssnano@6.1.2...cssnano@7.0.0)\r\n\r\n#### Breaking changes\r\n\r\nThis release drops official support for unmaintained long term support\r\nNode.js releases 14 and 16. It also drops support for non-long term\r\nsupport releases 19 and 21 and add support for Node.js 22. Only the\r\n`package.json` `engines` field has been updated. The code should\r\notherwise be identical to the previous 6.1.2 release.\r\n\r\nEnsuring support for older Node.js had become difficult as the GitHub\r\nactions runners are not available for the latest MacOS and recent pnpm\r\nalso could not run on CI any more.\r\n\r\n \r\n\r\n---\r\n\r\n### Configuration\r\n\r\n๐
**Schedule**: Branch creation - At any time (no schedule defined),\r\nAutomerge - At any time (no schedule defined).\r\n\r\n๐ฆ **Automerge**: Disabled by config. Please merge this manually once you\r\nare satisfied.\r\n\r\nโป **Rebasing**: Whenever PR becomes conflicted, or you tick the\r\nrebase/retry checkbox.\r\n\r\n๐ **Ignore**: Close this PR and you won't be reminded about this update\r\nagain.\r\n\r\n---\r\n\r\n- [ ] If you want to rebase/retry this PR, check\r\nthis box\r\n\r\n---\r\n\r\nThis PR has been generated by [Mend\r\nRenovate](https://www.mend.io/free-developer-tools/renovate/). View\r\nrepository job log\r\n[here](https://developer.mend.io/github/keithamus/hdx).\r\n\r\n\r\n\r\nCo-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>","shortMessageHtmlLink":"Update dependency cssnano to v7 (#17)"}},{"before":"e8178e0c3b5f6a7b04a19b1f17ed2ab2df80ac0a","after":null,"ref":"refs/heads/renovate/boa-dev-criterion-compare-action-digest","pushedAt":"2024-05-06T19:02:21.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"keithamus","name":"Keith Cirkel","path":"/keithamus","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/118266?s=80&v=4"}},{"before":"d94e66dc93a8b72e52c30d06762eb438aceac8bc","after":"c65db45cf2d446bbbb64e0fdbb3dbfdef665d8f4","ref":"refs/heads/main","pushedAt":"2024-05-06T19:02:21.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"keithamus","name":"Keith Cirkel","path":"/keithamus","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/118266?s=80&v=4"},"commit":{"message":"Update boa-dev/criterion-compare-action digest to 59f4d96 (#8)\n\n[](https://renovatebot.com)\r\n\r\nThis PR contains the following updates:\r\n\r\n| Package | Type | Update | Change |\r\n|---|---|---|---|\r\n| boa-dev/criterion-compare-action | action | digest | `adfd3a9` ->\r\n`59f4d96` |\r\n\r\n---\r\n\r\n### Configuration\r\n\r\n๐
**Schedule**: Branch creation - At any time (no schedule defined),\r\nAutomerge - At any time (no schedule defined).\r\n\r\n๐ฆ **Automerge**: Disabled by config. Please merge this manually once you\r\nare satisfied.\r\n\r\nโป **Rebasing**: Whenever PR becomes conflicted, or you tick the\r\nrebase/retry checkbox.\r\n\r\n๐ **Ignore**: Close this PR and you won't be reminded about this update\r\nagain.\r\n\r\n---\r\n\r\n- [ ] If you want to rebase/retry this PR, check\r\nthis box\r\n\r\n---\r\n\r\nThis PR has been generated by [Mend\r\nRenovate](https://www.mend.io/free-developer-tools/renovate/). View\r\nrepository job log\r\n[here](https://developer.mend.io/github/keithamus/hdx).\r\n\r\n\r\n\r\nCo-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>","shortMessageHtmlLink":"Update boa-dev/criterion-compare-action digest to 59f4d96 (#8)"}},{"before":null,"after":"e32a20a97edeee4cbebc3f4ab2f10c2d2722ac2b","ref":"refs/heads/renovate/postcss-import-16.x","pushedAt":"2024-05-06T19:00:45.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"renovate[bot]","name":null,"path":"/apps/renovate","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/2740?s=80&v=4"},"commit":{"message":"Update dependency postcss-import to v16","shortMessageHtmlLink":"Update dependency postcss-import to v16"}},{"before":null,"after":"d5261d24350eaa832f9f7e92a4b56d431ba0d283","ref":"refs/heads/renovate/cssnano-7.x","pushedAt":"2024-05-06T19:00:36.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"renovate[bot]","name":null,"path":"/apps/renovate","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/2740?s=80&v=4"},"commit":{"message":"Update dependency cssnano to v7","shortMessageHtmlLink":"Update dependency cssnano to v7"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEY5LXUAA","startCursor":null,"endCursor":null}},"title":"Activity ยท keithamus/hdx"}