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

chore(deps): update dependency esbuild to ^0.18.17 #35

Merged
merged 1 commit into from
Jul 29, 2023

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Jul 29, 2023

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
esbuild ^0.18.16 -> ^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 {}

Configuration

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

🚦 Automerge: Enabled.

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.

@codecov
Copy link

codecov bot commented Jul 29, 2023

Codecov Report

Merging #35 (ff3e18a) into main (1273705) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #35   +/-   ##
=======================================
  Coverage   87.50%   87.50%           
=======================================
  Files           1        1           
  Lines          24       24           
  Branches        3        3           
=======================================
  Hits           21       21           
  Partials        3        3           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@renovate renovate bot merged commit 8ac5e4c into main Jul 29, 2023
@renovate renovate bot deleted the renovate/all-minor-patch branch July 29, 2023 06:04
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.

0 participants