Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update dependency esbuild to v0.18.17 #251

Merged
merged 1 commit into from
Aug 1, 2023
Merged

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Jul 23, 2023

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
esbuild 0.18.15 -> 0.18.17 age adoption passing confidence

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.


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 Mend Renovate. View repository job log here.

@renovate renovate bot changed the title Update dependency esbuild to v0.18.16 Update dependency esbuild to v0.18.17 Jul 26, 2023
@lzm0x219 lzm0x219 merged commit 64aa9e4 into main Aug 1, 2023
2 checks passed
@lzm0x219 lzm0x219 deleted the renovate/esbuild-0.x branch August 1, 2023 02:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant