inhji/chiya
inhji/chiya
1
1
Fork 0
Code Issues 8 Pull requests 9 Activity

Update dependency esbuild to v0.18.17 #243

Merged
inhji merged 3 commits from renovate/esbuild-0.x-lockfile into devel 2023-08-02 20:49:24 +02:00
Conversation 1 Commits 3 Files changed 1 +92 -92
renovate commented 2023-07-29 18:16:53 +02:00
Collaborator
Copy link

This PR contains the following updates:

Package Type Update Change
esbuild devDependencies patch 0.18.14 -> 0.18.17

Release Notes

evanw/esbuild (esbuild)

v0.18.17

Compare Source

  • Support An+B syntax and :nth-*() pseudo-classes in CSS

    This adds support for the :nth-child(), :nth-last-child(), :nth-of-type(), and :nth-last-of-type() pseudo-classes to esbuild, which has the following consequences:

    • The An+B syntax is now parsed, so parse errors are now reported
    • An+B values inside these pseudo-classes are now pretty-printed (e.g. a leading + will be stripped because it's not in the AST)
    • When minification is enabled, An+B values are reduced to equivalent but shorter forms (e.g. 2n+0 => 2n, 2n+1 => odd)
    • Local CSS names in an of clause are now detected (e.g. in :nth-child(2n of :local(.foo)) the name foo is now renamed)
    /* Original code */
.foo:nth-child(+2n+1 of :local(.bar)) {
  color: red;
}

/* Old output (with --loader=local-css) */
.stdin_foo:nth-child(+2n + 1 of :local(.bar)) {
  color: red;
}

/* New output (with --loader=local-css) */
.stdin_foo:nth-child(2n+1 of .stdin_bar) {
  color: red;
}

  • Adjust CSS nesting parser for IE7 hacks (#​3272)

    This fixes a regression with esbuild's treatment of IE7 hacks in CSS. CSS nesting allows selectors to be used where declarations are expected. There's an IE7 hack where prefixing a declaration with a * causes that declaration to only be applied in IE7 due to a bug in IE7's CSS parser. However, it's valid for nested CSS selectors to start with *. So esbuild was incorrectly parsing these declarations and anything following it up until the next { as a selector for a nested CSS rule. This release changes esbuild's parser to terminate the parsing of selectors for nested CSS rules when a ; is encountered to fix this edge case:

    /* Original code */
.item {
  *width: 100%;
  height: 1px;
}

/* Old output */
.item {
  *width: 100%; height: 1px; {
  }
}

/* New output */
.item {
  *width: 100%;
  height: 1px;
}

    Note that the syntax for CSS nesting is about to change again, so esbuild's CSS parser may still not be completely accurate with how browsers do and/or will interpret CSS nesting syntax. Expect additional updates to esbuild's CSS parser in the future to deal with upcoming CSS specification changes.

  • Adjust esbuild's warning about undefined imports for TypeScript import equals declarations (#​3271)

    In JavaScript, accessing a missing property on an import namespace object is supposed to result in a value of undefined at run-time instead of an error at compile-time. This is something that esbuild warns you about by default because doing this can indicate a bug with your code. For example:

    // app.js
import * as styles from './styles'
console.log(styles.buton)

    // styles.js
export let button = {}

    If you bundle app.js with esbuild you will get this:

    ▲ [WARNING] Import "buton" will always be undefined because there is no matching export in "styles.js" [import-is-undefined]

    app.js:2:19:
      2 │ console.log(styles.buton)
        │                    ~~~~~
        ╵                    button

  Did you mean to import "button" instead?

    styles.js:1:11:
      1 │ export let button = {}
        ╵            ~~~~~~

    However, there is TypeScript-only syntax for import equals declarations that can represent either a type import (which esbuild should ignore) or a value import (which esbuild should respect). Since esbuild doesn't have a type system, it tries to only respect import equals declarations that are actually used as values. Previously esbuild always generated this warning for unused imports referenced within import equals declarations even when the reference could be a type instead of a value. Starting with this release, esbuild will now only warn in this case if the import is actually used. Here is an example of some code that no longer causes an incorrect warning:

    // app.ts
import * as styles from './styles'
import ButtonType = styles.Button

    // styles.ts
export interface Button {}

v0.18.16

Compare Source

  • Fix a regression with whitespace inside :is() (#​3265)

    The change to parse the contents of :is() in version 0.18.14 introduced a regression that incorrectly flagged the contents as a syntax error if the contents started with a whitespace token (for example div:is( .foo ) {}). This regression has been fixed.

v0.18.15

Compare Source

  • Add the --serve-fallback= option (#​2904)

    The web server built into esbuild serves the latest in-memory results of the configured build. If the requested path doesn't match any in-memory build result, esbuild also provides the --servedir= option to tell esbuild to serve the requested path from that directory instead. And if the requested path doesn't match either of those things, esbuild will either automatically generate a directory listing (for directories) or return a 404 error.

    Starting with this release, that last step can now be replaced with telling esbuild to serve a specific HTML file using the --serve-fallback= option. This can be used to provide a "not found" page for missing URLs. It can also be used to implement a single-page app that mutates the current URL and therefore requires the single app entry point to be served when the page is loaded regardless of whatever the current URL is.

  • Use the tsconfig field in package.json during extends resolution (#​3247)

    This release adds a feature from TypeScript 3.2 where if a tsconfig.json file specifies a package name in the extends field and that package's package.json file has a tsconfig field, the contents of that field are used in the search for the base tsconfig.json file.

  • Implement CSS nesting without :is() when possible (#​1945)

    Previously esbuild would always produce a warning when transforming nested CSS for a browser that doesn't support the :is() pseudo-class. This was because the nesting transform needs to generate an :is() in some complex cases which means the transformed CSS would then not work in that browser. However, the CSS nesting transform can often be done without generating an :is(). So with this release, esbuild will no longer warn when targeting browsers that don't support :is() in the cases where an :is() isn't needed to represent the nested CSS.

    In addition, esbuild's nested CSS transform has been updated to avoid generating an :is() in cases where an :is() is preferable but there's a longer alternative that is also equivalent. This update means esbuild can now generate a combinatorial explosion of CSS for complex CSS nesting syntax when targeting browsers that don't support :is(). This combinatorial explosion is necessary to accurately represent the original semantics. For example:

    /* Original code */
.first,
.second,
.third {
  & > & {
    color: red;
  }
}

/* Old output (with --target=chrome80) */
:is(.first, .second, .third) > :is(.first, .second, .third) {
  color: red;
}

/* New output (with --target=chrome80) */
.first > .first,
.first > .second,
.first > .third,
.second > .first,
.second > .second,
.second > .third,
.third > .first,
.third > .second,
.third > .third {
  color: red;
}

    This change means you can now use CSS nesting with esbuild when targeting an older browser that doesn't support :is(). You'll now only get a warning from esbuild if you use complex CSS nesting syntax that esbuild can't represent in that older browser without using :is(). There are two such cases:

    /* Case 1 */
a b {
  .foo & {
    color: red;
  }
}

/* Case 2 */
a {
  > b& {
    color: red;
  }
}

    These two cases still need to use :is(), both for different reasons, and cannot be used when targeting an older browser that doesn't support :is():

    /* Case 1 */
.foo :is(a b) {
  color: red;
}

/* Case 2 */
a > a:is(b) {
  color: red;
}

  • Automatically lower inset in CSS for older browsers

    With this release, esbuild will now automatically expand the inset property to the top, right, bottom, and left properties when esbuild's target is set to a browser that doesn't support inset:

    /* Original code */
.app {
  position: absolute;
  inset: 10px 20px;
}

/* Old output (with --target=chrome80) */
.app {
  position: absolute;
  inset: 10px 20px;
}

/* New output (with --target=chrome80) */
.app {
  position: absolute;
  top: 10px;
  right: 20px;
  bottom: 10px;
  left: 20px;
}

  • Add support for the new @starting-style CSS rule (#​3249)

    This at rule allow authors to start CSS transitions on first style update. That is, you can now make the transition take effect when the display property changes from none to block.

    /* Original code */
@​starting-style {
  h1 {
    background-color: transparent;
  }
}

/* Output */
@​starting-style{h1{background-color:transparent}}

    This was contributed by @​yisibl.

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [esbuild](https://github.com/evanw/esbuild) | devDependencies | patch | [`0.18.14` -> `0.18.17`](https://renovatebot.com/diffs/npm/esbuild/0.18.14/0.18.17) | --- ### Release Notes <details> <summary>evanw/esbuild (esbuild)</summary> ### [`v0.18.17`](https://github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01817) [Compare Source](https://github.com/evanw/esbuild/compare/v0.18.16...v0.18.17) - Support `An+B` syntax and `:nth-*()` pseudo-classes in CSS This adds support for the `:nth-child()`, `:nth-last-child()`, `:nth-of-type()`, and `:nth-last-of-type()` pseudo-classes to esbuild, which has the following consequences: - The [`An+B` syntax](https://drafts.csswg.org/css-syntax-3/#anb-microsyntax) is now parsed, so parse errors are now reported - `An+B` values inside these pseudo-classes are now pretty-printed (e.g. a leading `+` will be stripped because it's not in the AST) - When minification is enabled, `An+B` values are reduced to equivalent but shorter forms (e.g. `2n+0` => `2n`, `2n+1` => `odd`) - Local CSS names in an `of` clause are now detected (e.g. in `:nth-child(2n of :local(.foo))` the name `foo` is now renamed) ```css /* Original code */ .foo:nth-child(+2n+1 of :local(.bar)) { color: red; } /* Old output (with --loader=local-css) */ .stdin_foo:nth-child(+2n + 1 of :local(.bar)) { color: red; } /* New output (with --loader=local-css) */ .stdin_foo:nth-child(2n+1 of .stdin_bar) { color: red; } ``` - Adjust CSS nesting parser for IE7 hacks ([#&#8203;3272](https://github.com/evanw/esbuild/issues/3272)) This fixes a regression with esbuild's treatment of IE7 hacks in CSS. CSS nesting allows selectors to be used where declarations are expected. There's an IE7 hack where prefixing a declaration with a `*` causes that declaration to only be applied in IE7 due to a bug in IE7's CSS parser. However, it's valid for nested CSS selectors to start with `*`. So esbuild was incorrectly parsing these declarations and anything following it up until the next `{` as a selector for a nested CSS rule. This release changes esbuild's parser to terminate the parsing of selectors for nested CSS rules when a `;` is encountered to fix this edge case: ```css /* Original code */ .item { *width: 100%; height: 1px; } /* Old output */ .item { *width: 100%; height: 1px; { } } /* New output */ .item { *width: 100%; height: 1px; } ``` Note that the syntax for CSS nesting is [about to change again](https://github.com/w3c/csswg-drafts/issues/7961), so esbuild's CSS parser may still not be completely accurate with how browsers do and/or will interpret CSS nesting syntax. Expect additional updates to esbuild's CSS parser in the future to deal with upcoming CSS specification changes. - Adjust esbuild's warning about undefined imports for TypeScript `import` equals declarations ([#&#8203;3271](https://github.com/evanw/esbuild/issues/3271)) In JavaScript, accessing a missing property on an import namespace object is supposed to result in a value of `undefined` at run-time instead of an error at compile-time. This is something that esbuild warns you about by default because doing this can indicate a bug with your code. For example: ```js // app.js import * as styles from './styles' console.log(styles.buton) ``` ```js // styles.js export let button = {} ``` If you bundle `app.js` with esbuild you will get this: ▲ [WARNING] Import "buton" will always be undefined because there is no matching export in "styles.js" [import-is-undefined] app.js:2:19: 2 │ console.log(styles.buton) │ ~~~~~ ╵ button Did you mean to import "button" instead? styles.js:1:11: 1 │ export let button = {} ╵ ~~~~~~ However, there is TypeScript-only syntax for `import` equals declarations that can represent either a type import (which esbuild should ignore) or a value import (which esbuild should respect). Since esbuild doesn't have a type system, it tries to only respect `import` equals declarations that are actually used as values. Previously esbuild always generated this warning for unused imports referenced within `import` equals declarations even when the reference could be a type instead of a value. Starting with this release, esbuild will now only warn in this case if the import is actually used. Here is an example of some code that no longer causes an incorrect warning: ```ts // app.ts import * as styles from './styles' import ButtonType = styles.Button ``` ```ts // styles.ts export interface Button {} ``` ### [`v0.18.16`](https://github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01816) [Compare Source](https://github.com/evanw/esbuild/compare/v0.18.15...v0.18.16) - Fix a regression with whitespace inside `:is()` ([#&#8203;3265](https://github.com/evanw/esbuild/issues/3265)) The change to parse the contents of `:is()` in version 0.18.14 introduced a regression that incorrectly flagged the contents as a syntax error if the contents started with a whitespace token (for example `div:is( .foo ) {}`). This regression has been fixed. ### [`v0.18.15`](https://github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01815) [Compare Source](https://github.com/evanw/esbuild/compare/v0.18.14...v0.18.15) - Add the `--serve-fallback=` option ([#&#8203;2904](https://github.com/evanw/esbuild/issues/2904)) The web server built into esbuild serves the latest in-memory results of the configured build. If the requested path doesn't match any in-memory build result, esbuild also provides the `--servedir=` option to tell esbuild to serve the requested path from that directory instead. And if the requested path doesn't match either of those things, esbuild will either automatically generate a directory listing (for directories) or return a 404 error. Starting with this release, that last step can now be replaced with telling esbuild to serve a specific HTML file using the `--serve-fallback=` option. This can be used to provide a "not found" page for missing URLs. It can also be used to implement a [single-page app](https://en.wikipedia.org/wiki/Single-page_application) that mutates the current URL and therefore requires the single app entry point to be served when the page is loaded regardless of whatever the current URL is. - Use the `tsconfig` field in `package.json` during `extends` resolution ([#&#8203;3247](https://github.com/evanw/esbuild/issues/3247)) This release adds a feature from [TypeScript 3.2](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-2.html#tsconfigjson-inheritance-via-nodejs-packages) where if a `tsconfig.json` file specifies a package name in the `extends` field and that package's `package.json` file has a `tsconfig` field, the contents of that field are used in the search for the base `tsconfig.json` file. - Implement CSS nesting without `:is()` when possible ([#&#8203;1945](https://github.com/evanw/esbuild/issues/1945)) Previously esbuild would always produce a warning when transforming nested CSS for a browser that doesn't support the `:is()` pseudo-class. This was because the nesting transform needs to generate an `:is()` in some complex cases which means the transformed CSS would then not work in that browser. However, the CSS nesting transform can often be done without generating an `:is()`. So with this release, esbuild will no longer warn when targeting browsers that don't support `:is()` in the cases where an `:is()` isn't needed to represent the nested CSS. In addition, esbuild's nested CSS transform has been updated to avoid generating an `:is()` in cases where an `:is()` is preferable but there's a longer alternative that is also equivalent. This update means esbuild can now generate a combinatorial explosion of CSS for complex CSS nesting syntax when targeting browsers that don't support `:is()`. This combinatorial explosion is necessary to accurately represent the original semantics. For example: ```css /* Original code */ .first, .second, .third { & > & { color: red; } } /* Old output (with --target=chrome80) */ :is(.first, .second, .third) > :is(.first, .second, .third) { color: red; } /* New output (with --target=chrome80) */ .first > .first, .first > .second, .first > .third, .second > .first, .second > .second, .second > .third, .third > .first, .third > .second, .third > .third { color: red; } ``` This change means you can now use CSS nesting with esbuild when targeting an older browser that doesn't support `:is()`. You'll now only get a warning from esbuild if you use complex CSS nesting syntax that esbuild can't represent in that older browser without using `:is()`. There are two such cases: ```css /* Case 1 */ a b { .foo & { color: red; } } /* Case 2 */ a { > b& { color: red; } } ``` These two cases still need to use `:is()`, both for different reasons, and cannot be used when targeting an older browser that doesn't support `:is()`: ```css /* Case 1 */ .foo :is(a b) { color: red; } /* Case 2 */ a > a:is(b) { color: red; } ``` - Automatically lower `inset` in CSS for older browsers With this release, esbuild will now automatically expand the `inset` property to the `top`, `right`, `bottom`, and `left` properties when esbuild's `target` is set to a browser that doesn't support `inset`: ```css /* Original code */ .app { position: absolute; inset: 10px 20px; } /* Old output (with --target=chrome80) */ .app { position: absolute; inset: 10px 20px; } /* New output (with --target=chrome80) */ .app { position: absolute; top: 10px; right: 20px; bottom: 10px; left: 20px; } ``` - Add support for the new [`@starting-style`](https://drafts.csswg.org/css-transitions-2/#defining-before-change-style-the-starting-style-rule) CSS rule ([#&#8203;3249](https://github.com/evanw/esbuild/pull/3249)) This at rule allow authors to start CSS transitions on first style update. That is, you can now make the transition take effect when the `display` property changes from `none` to `block`. ```css /* Original code */ @&#8203;starting-style { h1 { background-color: transparent; } } /* Output */ @&#8203;starting-style{h1{background-color:transparent}} ``` This was contributed by [@&#8203;yisibl](https://github.com/yisibl). </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNi4yNS41IiwidXBkYXRlZEluVmVyIjoiMzYuMjUuNSIsInRhcmdldEJyYW5jaCI6ImRldmVsIn0=-->
renovate added 1 commit 2023-07-29 18:16:54 +02:00
renovate force-pushed renovate/esbuild-0.x-lockfile from f504093545 to abf1f6d1f2 2023-07-29 18:40:37 +02:00 Compare
renovate force-pushed renovate/esbuild-0.x-lockfile from abf1f6d1f2 to 999e395a81 2023-07-29 18:50:43 +02:00 Compare
renovate force-pushed renovate/esbuild-0.x-lockfile from 999e395a81 to c8b5ae35b9 2023-07-29 19:00:39 +02:00 Compare
renovate force-pushed renovate/esbuild-0.x-lockfile from c8b5ae35b9 to ffb2a93610 2023-07-29 19:10:39 +02:00 Compare
inhji added 1 commit 2023-08-01 07:32:59 +02:00
renovate commented 2023-08-01 08:00:26 +02:00
Author
Collaborator
Copy link

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠ Warning: custom changes will be lost.

### Edited/Blocked Notification Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. ⚠ **Warning**: custom changes will be lost.
inhji added 1 commit 2023-08-02 20:49:06 +02:00
inhji merged commit b14777cd9b into devel 2023-08-02 20:49:24 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
ActivityPub

   
Bug

   
Indie/Micropub

   
Indie/Microsub

   
Indie/Webmention

   
Special/MEGA

   
Special/Renovate
No labels
ActivityPub
Bug
Indie/Micropub
Indie/Microsub
Indie/Webmention
Special/MEGA
Special/Renovate
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference: inhji/chiya#243
No description provided.
Delete branch "renovate/esbuild-0.x-lockfile"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?