{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":685727052,"defaultBranch":"main","name":"lonboard","ownerLogin":"developmentseed","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2023-08-31T21:48:10.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/92384?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1721017921.0","currentOid":""},"activityList":{"items":[{"before":"d6c27401fec4e1c2804a348d7c5ccc7b5f3d8543","after":null,"ref":"refs/heads/dependabot/npm_and_yarn/deck-loaders-luma-0b212b5c65","pushedAt":"2024-07-15T04:32:01.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"dependabot[bot]","name":null,"path":"/apps/dependabot","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/29110?s=80&v=4"}},{"before":null,"after":"03ebd825d18b70f7b3d79bae0c8645ad575f11a1","ref":"refs/heads/dependabot/npm_and_yarn/deck-loaders-luma-9065c1d308","pushedAt":"2024-07-15T04:31:57.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"dependabot[bot]","name":null,"path":"/apps/dependabot","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/29110?s=80&v=4"},"commit":{"message":"Bump the deck-loaders-luma group across 1 directory with 4 updates\n\nBumps the deck-loaders-luma group with 4 updates in the / directory: [@deck.gl/core](https://github.com/visgl/deck.gl), [@deck.gl/extensions](https://github.com/visgl/deck.gl), [@deck.gl/layers](https://github.com/visgl/deck.gl) and [@deck.gl/react](https://github.com/visgl/deck.gl).\n\n\nUpdates `@deck.gl/core` from 8.9.35 to 9.0.23\n- [Release notes](https://github.com/visgl/deck.gl/releases)\n- [Changelog](https://github.com/visgl/deck.gl/blob/v9.0.23/CHANGELOG.md)\n- [Commits](https://github.com/visgl/deck.gl/compare/v8.9.35...v9.0.23)\n\nUpdates `@deck.gl/extensions` from 8.9.35 to 9.0.23\n- [Release notes](https://github.com/visgl/deck.gl/releases)\n- [Changelog](https://github.com/visgl/deck.gl/blob/v9.0.23/CHANGELOG.md)\n- [Commits](https://github.com/visgl/deck.gl/compare/v8.9.35...v9.0.23)\n\nUpdates `@deck.gl/layers` from 8.9.35 to 9.0.23\n- [Release notes](https://github.com/visgl/deck.gl/releases)\n- [Changelog](https://github.com/visgl/deck.gl/blob/v9.0.23/CHANGELOG.md)\n- [Commits](https://github.com/visgl/deck.gl/compare/v8.9.35...v9.0.23)\n\nUpdates `@deck.gl/react` from 8.9.35 to 9.0.23\n- [Release notes](https://github.com/visgl/deck.gl/releases)\n- [Changelog](https://github.com/visgl/deck.gl/blob/v9.0.23/CHANGELOG.md)\n- [Commits](https://github.com/visgl/deck.gl/compare/v8.9.35...v9.0.23)\n\n---\nupdated-dependencies:\n- dependency-name: \"@deck.gl/core\"\n dependency-type: direct:production\n update-type: version-update:semver-major\n dependency-group: deck-loaders-luma\n- dependency-name: \"@deck.gl/extensions\"\n dependency-type: direct:production\n update-type: version-update:semver-major\n dependency-group: deck-loaders-luma\n- dependency-name: \"@deck.gl/layers\"\n dependency-type: direct:production\n update-type: version-update:semver-major\n dependency-group: deck-loaders-luma\n- dependency-name: \"@deck.gl/react\"\n dependency-type: direct:production\n update-type: version-update:semver-major\n dependency-group: deck-loaders-luma\n...\n\nSigned-off-by: dependabot[bot] Sourced from esbuild's\r\nreleases. This release deliberately contains backwards-incompatible\r\nchanges. To avoid automatically picking up releases like\r\nthis, you should either be pinning the exact version of\r\n Revert the recent change to avoid bundling dependencies for node (#3819) This release reverts the recent change in version 0.22.0 that made\r\n I've just been made aware that Amazon doesn't pin their dependencies\r\nin their "AWS CDK" product, which means that whenever esbuild\r\npublishes a new release, many people (potentially everyone?) using their\r\nSDK around the world instantly starts using it without Amazon checking\r\nthat it works first. This change in version 0.22.0 happened to break\r\ntheir SDK. I'm amazed that things haven't broken before this point. This\r\nrevert attempts to avoid these problems for Amazon's customers.\r\nHopefully Amazon will pin their dependencies in the future. In addition, this is probably a sign that esbuild is used widely\r\nenough that it now needs to switch to a more complicated release model.\r\nI may have esbuild use a beta channel model for further development. Fix preserving collapsed JSX whitespace (#3818) When transformed, certain whitespace inside JSX elements is ignored\r\ncompletely if it collapses to an empty string. However, the whitespace\r\nshould only be ignored if the JSX is being transformed, not if it's\r\nbeing preserved. This release fixes a bug where esbuild was previously\r\nincorrectly ignoring collapsed whitespace with\r\n // Old output (with --jsx=preserve) // New output (with --jsx=preserve)Release notes
\r\n\r\n
v0.23.0
\r\nesbuild
in your package.json
file\r\n(recommended) or be using a version range syntax that only accepts patch\r\nupgrades such as ^0.22.0
or ~0.22.0
. See npm's\r\ndocumentation about semver for\r\nmore information.\r\n
--packages=external
the default behavior with\r\n--platform=node
. The default is now back to\r\n--packages=bundle
.--jsx=preserve
. Here is an example:// Original code\r\n<Foo>\r\n <Bar />\r\n</Foo>\r\n
\r\n<Foo><Bar /></Foo>;
\r\n<Foo>
\r\n<Bar />
\r\n</Foo>;
\r\n
Sourced from esbuild's\r\nchangelog.
\r\n\r\n\r\n0.23.0
\r\nThis release deliberately contains backwards-incompatible\r\nchanges. To avoid automatically picking up releases like\r\nthis, you should either be pinning the exact version of\r\n
\r\nesbuild
in yourpackage.json
file\r\n(recommended) or be using a version range syntax that only accepts patch\r\nupgrades such as^0.22.0
or~0.22.0
. See npm's\r\ndocumentation about semver for\r\nmore information.\r\n
\r\n- \r\n
\r\nRevert the recent change to avoid bundling dependencies for node (#3819)
\r\nThis release reverts the recent change in version 0.22.0 that made\r\n
\r\n--packages=external
the default behavior with\r\n--platform=node
. The default is now back to\r\n--packages=bundle
.I've just been made aware that Amazon doesn't pin their dependencies\r\nin their "AWS CDK" product, which means that whenever esbuild\r\npublishes a new release, many people (potentially everyone?) using their\r\nSDK around the world instantly starts using it without Amazon checking\r\nthat it works first. This change in version 0.22.0 happened to break\r\ntheir SDK. I'm amazed that things haven't broken before this point. This\r\nrevert attempts to avoid these problems for Amazon's customers.\r\nHopefully Amazon will pin their dependencies in the future.
\r\nIn addition, this is probably a sign that esbuild is used widely\r\nenough that it now needs to switch to a more complicated release model.\r\nI may have esbuild use a beta channel model for further development.
\r\n- \r\n
\r\nFix preserving collapsed JSX whitespace (#3818)
\r\nWhen transformed, certain whitespace inside JSX elements is ignored\r\ncompletely if it collapses to an empty string. However, the whitespace\r\nshould only be ignored if the JSX is being transformed, not if it's\r\nbeing preserved. This release fixes a bug where esbuild was previously\r\nincorrectly ignoring collapsed whitespace with\r\n
\r\n--jsx=preserve
. Here is an example:\r\n// Original code\r\n<Foo>\r\n <Bar />\r\n</Foo>\r\n
// Old output (with --jsx=preserve)
\r\n
\r\n<Foo><Bar /></Foo>;// New output (with --jsx=preserve)
\r\n<Foo>
\r\n<Bar />
\r\n</Foo>;
\r\n
Sourced from typescript's\r\nreleases.
\r\n\r\n\r\nTypeScript 5.5.3
\r\nFor release notes, check out the release\r\nannouncement.
\r\nFor the complete list of fixed issues, check out the
\r\n\r\n
\r\n- fixed\r\nissues query for TypeScript v5.5.3 (Stable).
\r\n- fixed\r\nissues query for TypeScript v5.5.2 (Stable).
\r\n- fixed\r\nissues query for TypeScript v5.5.1 (RC).
\r\n- fixed\r\nissues query for TypeScript v5.5.0 (Beta).
\r\nDownloads are available on:
\r\n\r\n
\r\n- npm
\r\n- NuGet\r\npackage
\r\n
f0e9921
\r\nBump version to 5.5.3 and LKG738bd60
\r\nCherry-pick #58966\r\nto release-5.5 (#59002)Sourced from esbuild's\r\nreleases.
\r\n\r\n\r\nv0.22.0
\r\nThis release deliberately contains backwards-incompatible\r\nchanges. To avoid automatically picking up releases like this,\r\nyou should either be pinning the exact version of
\r\nesbuild
\r\nin yourpackage.json
file (recommended) or be using a\r\nversion range syntax that only accepts patch upgrades such as\r\n^0.21.0
or~0.21.0
. See npm's documentation\r\nabout semver for\r\nmore information.\r\n
\r\n\r\n- \r\n
\r\nOmit packages from bundles by default when targeting node (#1874,\r\n#2830,\r\n#2846,\r\n#2915,\r\n#3145,\r\n#3294,\r\n#3323,\r\n#3582,\r\n#3809,\r\n#3815)
\r\nThis breaking change is an experiment. People are commonly confused\r\nwhen using esbuild to bundle code for node (i.e. for\r\n
\r\n--platform=node
) because some packages may not be intended\r\nfor bundlers, and may use node-specific features that don't work with a\r\nbundler. Even though esbuild's "getting started" instructions\r\nsay to use--packages=external
to work around this problem,\r\nmany people don't read the documentation and don't do this, and are then\r\nconfused when it doesn't work. So arguably this is a bad default\r\nbehavior for esbuild to have if people keep tripping over this.With this release, esbuild will now omit packages from the bundle by\r\ndefault when the platform is
\r\nnode
(i.e. the previous\r\nbehavior of--packages=external
is now the default in this\r\ncase). Note that your dependencies must now be present on the file\r\nsystem when your bundle is run. If you don't want this behavior,\r\nyou can do--packages=bundle
to allow packages to be\r\nincluded in the bundle (i.e. the previous default behavior). Note that\r\n--packages=bundle
doesn't mean all packages are bundled,\r\njust that packages are allowed to be bundled. You can still exclude\r\nindividual packages from the bundle using--external:
even\r\nwhen--packages=bundle
is present.The
\r\n--packages=
setting considers all import paths that\r\n"look like" package imports in the original source code to be\r\npackage imports. Specifically import paths that don't start with a path\r\nsegment of/
or.
or..
are\r\nconsidered to be package imports. The only two exceptions to this rule\r\nare subpath\r\nimports (which start with a#
character) and TypeScript\r\npath remappings viapaths
and/orbaseUrl
in\r\ntsconfig.json
(which are applied first).- \r\n
\r\nDrop support for older platforms (#3802)
\r\nThis release drops support for the following operating systems:
\r\n\r\n
\r\n- Windows 7
\r\n- Windows 8
\r\n- Windows Server 2008
\r\n- Windows Server 2012
\r\nThis is because the Go programming language dropped support for these\r\noperating system versions in Go 1.21, and this release\r\nupdates esbuild from Go 1.20 to Go 1.22.
\r\nNote that this only affects the binary esbuild executables that are\r\npublished to the
\r\nesbuild
npm package. It's still possible\r\nto compile esbuild's source code for these older operating systems. If\r\nyou need to, you can compile esbuild for yourself using an older version\r\nof the Go compiler (before Go version 1.21). That might look something\r\nlike this:\r\ngit clone https://github.com/evanw/esbuild.git\r\ncd esbuild\r\ngo build ./cmd/esbuild\r\n./esbuild.exe --version\r\n
In addition, this release increases the minimum required node version\r\nfor esbuild's JavaScript API from node 12 to node 18. Node 18 is the\r\noldest version of node that is still being supported (see node's release\r\nschedule for more information). This increase is because of an\r\nincompatibility between the JavaScript that the Go compiler generates\r\nfor the
\r\nesbuild-wasm
package and versions of node before\r\nnode 17.4 (specifically thecrypto.getRandomValues
\r\nfunction).- \r\n
\r\nUpdate
\r\nawait using
behavior to match TypeScriptTypeScript 5.5 subtly changes the way
\r\nawait using
\r\nbehaves. This release updates esbuild to match these changes in\r\nTypeScript. You can read more about these changes in microsoft/TypeScript#58624.- \r\n
\r\nAllow
\r\nes2024
as a target environmentThe ECMAScript 2024 specification was just approved, so it has been\r\nadded to esbuild as a possible compilation target. You can read more\r\nabout the features that it adds here: https://2ality.com/2024/06/ecmascript-2024.html.\r\nThe only addition that's relevant for esbuild is the regular expression\r\n
\r\n/v
flag. With--target=es2024
, regular\r\nexpressions that use the/v
flag will now be passed through\r\nuntransformed instead of being transformed into a call tonew\r\nRegExp
.- \r\n
\r\nPublish binaries for OpenBSD on 64-bit ARM (#3665,\r\n#3674)
\r\nWith this release, you should now be able to install the\r\n
\r\nesbuild
npm package in OpenBSD on 64-bit ARM, such as on an\r\nApple device with an M1 chip.This was contributed by
\r\n@ikmckenz
.- \r\n
\r\nPublish binaries for WASI (WebAssembly System Interface) preview 1\r\n(#3300,\r\n#3779)
\r\nThe upcoming WASI (WebAssembly System Interface) standard is going to\r\nbe a way to run WebAssembly outside of a JavaScript host environment. In\r\nthis scenario you only need a
\r\n.wasm
file without any\r\nsupporting JavaScript code. Instead of JavaScript providing the APIs for\r\nthe host environment, the WASI standard specifies a "system\r\ninterface" that WebAssembly code can access directly (e.g. for file\r\nsystem access).
... (truncated)
\r\nSourced from esbuild's\r\nchangelog.
\r\n\r\n\r\n0.22.0
\r\nThis release deliberately contains backwards-incompatible\r\nchanges. To avoid automatically picking up releases like this,\r\nyou should either be pinning the exact version of
\r\nesbuild
\r\nin yourpackage.json
file (recommended) or be using a\r\nversion range syntax that only accepts patch upgrades such as\r\n^0.21.0
or~0.21.0
. See npm's documentation\r\nabout semver for\r\nmore information.\r\n
\r\n\r\n- \r\n
\r\nOmit packages from bundles by default when targeting node (#1874,\r\n#2830,\r\n#2846,\r\n#2915,\r\n#3145,\r\n#3294,\r\n#3323,\r\n#3582,\r\n#3809,\r\n#3815)
\r\nThis breaking change is an experiment. People are commonly confused\r\nwhen using esbuild to bundle code for node (i.e. for\r\n
\r\n--platform=node
) because some packages may not be intended\r\nfor bundlers, and may use node-specific features that don't work with a\r\nbundler. Even though esbuild's "getting started" instructions\r\nsay to use--packages=external
to work around this problem,\r\nmany people don't read the documentation and don't do this, and are then\r\nconfused when it doesn't work. So arguably this is a bad default\r\nbehavior for esbuild to have if people keep tripping over this.With this release, esbuild will now omit packages from the bundle by\r\ndefault when the platform is
\r\nnode
(i.e. the previous\r\nbehavior of--packages=external
is now the default in this\r\ncase). Note that your dependencies must now be present on the file\r\nsystem when your bundle is run. If you don't want this behavior,\r\nyou can do--packages=bundle
to allow packages to be\r\nincluded in the bundle (i.e. the previous default behavior). Note that\r\n--packages=bundle
doesn't mean all packages are bundled,\r\njust that packages are allowed to be bundled. You can still exclude\r\nindividual packages from the bundle using--external:
even\r\nwhen--packages=bundle
is present.The
\r\n--packages=
setting considers all import paths that\r\n"look like" package imports in the original source code to be\r\npackage imports. Specifically import paths that don't start with a path\r\nsegment of/
or.
or..
are\r\nconsidered to be package imports. The only two exceptions to this rule\r\nare subpath\r\nimports (which start with a#
character) and TypeScript\r\npath remappings viapaths
and/orbaseUrl
in\r\ntsconfig.json
(which are applied first).- \r\n
\r\nDrop support for older platforms (#3802)
\r\nThis release drops support for the following operating systems:
\r\n\r\n
\r\n- Windows 7
\r\n- Windows 8
\r\n- Windows Server 2008
\r\n- Windows Server 2012
\r\nThis is because the Go programming language dropped support for these\r\noperating system versions in Go 1.21, and this release\r\nupdates esbuild from Go 1.20 to Go 1.22.
\r\nNote that this only affects the binary esbuild executables that are\r\npublished to the
\r\nesbuild
npm package. It's still possible\r\nto compile esbuild's source code for these older operating systems. If\r\nyou need to, you can compile esbuild for yourself using an older version\r\nof the Go compiler (before Go version 1.21). That might look something\r\nlike this:\r\ngit clone https://github.com/evanw/esbuild.git\r\ncd esbuild\r\ngo build ./cmd/esbuild\r\n./esbuild.exe --version\r\n
In addition, this release increases the minimum required node version\r\nfor esbuild's JavaScript API from node 12 to node 18. Node 18 is the\r\noldest version of node that is still being supported (see node's release\r\nschedule for more information). This increase is because of an\r\nincompatibility between the JavaScript that the Go compiler generates\r\nfor the
\r\nesbuild-wasm
package and versions of node before\r\nnode 17.4 (specifically thecrypto.getRandomValues
\r\nfunction).- \r\n
\r\nUpdate
\r\nawait using
behavior to match TypeScriptTypeScript 5.5 subtly changes the way
\r\nawait using
\r\nbehaves. This release updates esbuild to match these changes in\r\nTypeScript. You can read more about these changes in microsoft/TypeScript#58624.- \r\n
\r\nAllow
\r\nes2024
as a target environmentThe ECMAScript 2024 specification was just approved, so it has been\r\nadded to esbuild as a possible compilation target. You can read more\r\nabout the features that it adds here: https://2ality.com/2024/06/ecmascript-2024.html.\r\nThe only addition that's relevant for esbuild is the regular expression\r\n
\r\n/v
flag. With--target=es2024
, regular\r\nexpressions that use the/v
flag will now be passed through\r\nuntransformed instead of being transformed into a call tonew\r\nRegExp
.- \r\n
\r\nPublish binaries for OpenBSD on 64-bit ARM (#3665,\r\n#3674)
\r\nWith this release, you should now be able to install the\r\n
\r\nesbuild
npm package in OpenBSD on 64-bit ARM, such as on an\r\nApple device with an M1 chip.This was contributed by
\r\n@ikmckenz
.- \r\n
\r\nPublish binaries for WASI (WebAssembly System Interface) preview 1\r\n(#3300,\r\n#3779)
\r\n
... (truncated)
\r\n80c6e6e
\r\npublish 0.22.0 to npm196dcad
\r\nfix #1874:\r\nnode defaults to --packages=external
3f57db8
\r\nrelease notes for #353991663db
\r\nProvide API to create a custom esbuild CLI with plugins (#3539)e01c0e0
\r\nalso mention #3665\r\nin release notes65711b3
\r\nrelease notes for #367463eb814
\r\nAdd OpenBSD arm64 (#3674)b722000
\r\nfix #3300,\r\nfix #3779:\r\nadd @esbuild/wasi-preview1
6679ec8
\r\nfix: verbose analyse output improperly trimmed (#3785)94f09ea
\r\nfix #3790:\r\nwarn about incorrect onResolve
plugin