octokit/rest.js
### [`v19.0.4`](https://togithub.com/octokit/rest.js/releases/tag/v19.0.4)
[Compare Source](https://togithub.com/octokit/rest.js/compare/v19.0.3...v19.0.4)
##### Bug Fixes
- **deps:** update dependency [@octokit/plugin-paginate-rest](https://togithub.com/octokit/plugin-paginate-rest) to v4 ([#187](https://togithub.com/octokit/rest.js/issues/187)) ([4e18c8d](https://togithub.com/octokit/rest.js/commit/4e18c8d80a95ec21b56637beb195cc8296293551))
evanw/esbuild
### [`v0.15.5`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0155)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.15.4...v0.15.5)
- Fix issues with Yarn PnP and Yarn's workspaces feature ([#2476](https://togithub.com/evanw/esbuild/issues/2476))
This release makes sure esbuild works with a Yarn feature called [workspaces](https://yarnpkg.com/features/workspaces/). Previously esbuild wasn't tested in this scenario, but this scenario now has test coverage. Getting this to work involved further tweaks to esbuild's custom code for what happens after Yarn PnP's path resolution algorithm runs, which is not currently covered by Yarn's PnP specification. These tweaks also fix `exports` map resolution with Yarn PnP for non-empty subpaths, which wasn't previously working.
### [`v0.15.4`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0154)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.15.3...v0.15.4)
- Consider TypeScript import assignments to be side-effect free ([#2468](https://togithub.com/evanw/esbuild/issues/2468))
TypeScript has a [legacy import syntax](https://www.typescriptlang.org/docs/handbook/namespaces.html#aliases) for working with TypeScript namespaces that looks like this:
```ts
import { someNamespace } from './some-file'
import bar = someNamespace.foo;
// some-file.ts
export namespace someNamespace {
export let foo = 123
}
```
Since esbuild converts TypeScript into JavaScript one file at a time, it doesn't know if `bar` is supposed to be a value or a type (or both, which TypeScript actually allows in this case). This is problematic because values are supposed to be kept during the conversion but types are supposed to be removed during the conversion. Currently esbuild keeps `bar` in the output, which is done because `someNamespace.foo` is a property access and property accesses run code that could potentially have a side effect (although there is no side effect in this case).
With this release, esbuild will now consider `someNamespace.foo` to have no side effects. This means `bar` will now be removed when bundling and when tree shaking is enabled. Note that it will still not be removed when tree shaking is disabled. This is because in this mode, esbuild supports adding additional code to the end of the generated output that's in the same scope as the module. That code could potentially make use of `bar`, so it would be incorrect to remove it. If you want `bar` to be removed, you'll have to enable tree shaking (which tells esbuild that nothing else depends on the unexported top-level symbols in the generated output).
- Change the order of the banner and the `"use strict"` directive ([#2467](https://togithub.com/evanw/esbuild/issues/2467))
Previously the top of the file contained the following things in order:
1. The hashbang comment (see below) from the source code, if present
2. The `"use strict"` directive from the source code, if present
3. The content of esbuild's `banner` API option, if specified
This was problematic for people that used the `banner` API option to insert the hashbang comment instead of using esbuild's hashbang comment preservation feature. So with this release, the order has now been changed to:
1. The hashbang comment (see below) from the source code, if present
2. The content of esbuild's `banner` API option, if specified
3. The `"use strict"` directive from the source code, if present
I'm considering this change to be a bug fix instead of a breaking change because esbuild's documentation states that the `banner` API option can be used to "insert an arbitrary string at the beginning of generated JavaScript files". While this isn't technically true because esbuild may still insert the original hashbang comment before the banner, it's at least more correct now because the banner will now come before the `"use strict"` directive.
For context: JavaScript files recently allowed using a [hashbang comment](https://togithub.com/tc39/proposal-hashbang), which starts with `#!` and which must start at the very first character of the file. It allows Unix systems to execute the file directly as a script without needing to prefix it by the `node` command. This comment typically has the value `#!/usr/bin/env node`. Hashbang comments will be a part of ES2023 when it's released next year.
- Fix `exports` maps with Yarn PnP path resolution ([#2473](https://togithub.com/evanw/esbuild/issues/2473))
The Yarn PnP specification says that to resolve a package path, you first resolve it to the absolute path of a directory, and then you run node's module resolution algorithm on it. Previously esbuild followed this part of the specification. However, doing this means that `exports` in `package.json` is not respected because node's module resolution algorithm doesn't interpret `exports` for absolute paths. So with this release, esbuild will now use a modified algorithm that deviates from both specifications but that should hopefully behave more similar to what Yarn actually does: node's module resolution algorithm is run with the original import path but starting from the directory returned by Yarn PnP.
Configuration
📅 Schedule: Branch creation - "every weekend" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
[ ] If you want to rebase/retry this PR, click this checkbox.
This PR has been generated by Mend Renovate. View repository job log here.
This PR contains the following updates:
19.0.3->19.0.428.1.6->28.1.716.11.48->16.11.512.7.22->2.7.250.15.3->0.15.5Release Notes
octokit/rest.js
### [`v19.0.4`](https://togithub.com/octokit/rest.js/releases/tag/v19.0.4) [Compare Source](https://togithub.com/octokit/rest.js/compare/v19.0.3...v19.0.4) ##### Bug Fixes - **deps:** update dependency [@octokit/plugin-paginate-rest](https://togithub.com/octokit/plugin-paginate-rest) to v4 ([#187](https://togithub.com/octokit/rest.js/issues/187)) ([4e18c8d](https://togithub.com/octokit/rest.js/commit/4e18c8d80a95ec21b56637beb195cc8296293551))evanw/esbuild
### [`v0.15.5`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0155) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.15.4...v0.15.5) - Fix issues with Yarn PnP and Yarn's workspaces feature ([#2476](https://togithub.com/evanw/esbuild/issues/2476)) This release makes sure esbuild works with a Yarn feature called [workspaces](https://yarnpkg.com/features/workspaces/). Previously esbuild wasn't tested in this scenario, but this scenario now has test coverage. Getting this to work involved further tweaks to esbuild's custom code for what happens after Yarn PnP's path resolution algorithm runs, which is not currently covered by Yarn's PnP specification. These tweaks also fix `exports` map resolution with Yarn PnP for non-empty subpaths, which wasn't previously working. ### [`v0.15.4`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0154) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.15.3...v0.15.4) - Consider TypeScript import assignments to be side-effect free ([#2468](https://togithub.com/evanw/esbuild/issues/2468)) TypeScript has a [legacy import syntax](https://www.typescriptlang.org/docs/handbook/namespaces.html#aliases) for working with TypeScript namespaces that looks like this: ```ts import { someNamespace } from './some-file' import bar = someNamespace.foo; // some-file.ts export namespace someNamespace { export let foo = 123 } ``` Since esbuild converts TypeScript into JavaScript one file at a time, it doesn't know if `bar` is supposed to be a value or a type (or both, which TypeScript actually allows in this case). This is problematic because values are supposed to be kept during the conversion but types are supposed to be removed during the conversion. Currently esbuild keeps `bar` in the output, which is done because `someNamespace.foo` is a property access and property accesses run code that could potentially have a side effect (although there is no side effect in this case). With this release, esbuild will now consider `someNamespace.foo` to have no side effects. This means `bar` will now be removed when bundling and when tree shaking is enabled. Note that it will still not be removed when tree shaking is disabled. This is because in this mode, esbuild supports adding additional code to the end of the generated output that's in the same scope as the module. That code could potentially make use of `bar`, so it would be incorrect to remove it. If you want `bar` to be removed, you'll have to enable tree shaking (which tells esbuild that nothing else depends on the unexported top-level symbols in the generated output). - Change the order of the banner and the `"use strict"` directive ([#2467](https://togithub.com/evanw/esbuild/issues/2467)) Previously the top of the file contained the following things in order: 1. The hashbang comment (see below) from the source code, if present 2. The `"use strict"` directive from the source code, if present 3. The content of esbuild's `banner` API option, if specified This was problematic for people that used the `banner` API option to insert the hashbang comment instead of using esbuild's hashbang comment preservation feature. So with this release, the order has now been changed to: 1. The hashbang comment (see below) from the source code, if present 2. The content of esbuild's `banner` API option, if specified 3. The `"use strict"` directive from the source code, if present I'm considering this change to be a bug fix instead of a breaking change because esbuild's documentation states that the `banner` API option can be used to "insert an arbitrary string at the beginning of generated JavaScript files". While this isn't technically true because esbuild may still insert the original hashbang comment before the banner, it's at least more correct now because the banner will now come before the `"use strict"` directive. For context: JavaScript files recently allowed using a [hashbang comment](https://togithub.com/tc39/proposal-hashbang), which starts with `#!` and which must start at the very first character of the file. It allows Unix systems to execute the file directly as a script without needing to prefix it by the `node` command. This comment typically has the value `#!/usr/bin/env node`. Hashbang comments will be a part of ES2023 when it's released next year. - Fix `exports` maps with Yarn PnP path resolution ([#2473](https://togithub.com/evanw/esbuild/issues/2473)) The Yarn PnP specification says that to resolve a package path, you first resolve it to the absolute path of a directory, and then you run node's module resolution algorithm on it. Previously esbuild followed this part of the specification. However, doing this means that `exports` in `package.json` is not respected because node's module resolution algorithm doesn't interpret `exports` for absolute paths. So with this release, esbuild will now use a modified algorithm that deviates from both specifications but that should hopefully behave more similar to what Yarn actually does: node's module resolution algorithm is run with the original import path but starting from the directory returned by Yarn PnP.Configuration
📅 Schedule: Branch creation - "every weekend" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Mend Renovate. View repository job log here.