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.

Sign up for GitHub

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

Jump to bottom

Update minors and patches #41

Merged
merged 2 commits into from
Jun 9, 2023
Merged

Update minors and patches #41

merged 2 commits into from
Jun 9, 2023

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Jun 3, 2023 •
edited
Loading

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@google-cloud/pubsub ^3.5.2 -> ^3.7.1 age adoption passing confidence
@types/node (source) ^18.16.5 -> ^18.16.16 age adoption passing confidence
@typescript-eslint/eslint-plugin ^5.59.2 -> ^5.59.9 age adoption passing confidence
@typescript-eslint/parser ^5.59.2 -> ^5.59.9 age adoption passing confidence
@typescript-eslint/typescript-estree ^5.59.2 -> ^5.59.9 age adoption passing confidence
@typescript-eslint/utils ^5.59.2 -> ^5.59.9 age adoption passing confidence
@vitest/coverage-c8 (source) ^0.31.0 -> ^0.32.0 age adoption passing confidence
dotenv ^16.0.3 -> ^16.1.4 age adoption passing confidence
esbuild ^0.17.18 -> ^0.18.0 age adoption passing confidence
eslint (source) ^8.40.0 -> ^8.42.0 age adoption passing confidence
msw (source) ^1.2.1 -> ^1.2.2 age adoption passing confidence
typescript (source) ^5.0.4 -> ^5.1.3 age adoption passing confidence
undici (source) ^5.22.0 -> ^5.22.1 age adoption passing confidence
vitest ^0.31.0 -> ^0.32.0 age adoption passing confidence

Release Notes

googleapis/nodejs-pubsub

v3.7.1

Compare Source

Bug Fixes
  • Don't crash if an already-drained/removed queue gets flushed again (#​1747) (52ea441)

v3.7.0

Compare Source

Features

v3.6.0

Compare Source

Features
typescript-eslint/typescript-eslint (@​typescript-eslint/eslint-plugin)

v5.59.9

Compare Source

Note: Version bump only for package @​typescript-eslint/eslint-plugin

v5.59.8

Compare Source

Note: Version bump only for package @​typescript-eslint/eslint-plugin

v5.59.7

Compare Source

Note: Version bump only for package @​typescript-eslint/eslint-plugin

v5.59.6

Compare Source

Note: Version bump only for package @​typescript-eslint/eslint-plugin

v5.59.5

Compare Source

Note: Version bump only for package @​typescript-eslint/eslint-plugin

typescript-eslint/typescript-eslint (@​typescript-eslint/parser)

v5.59.9

Compare Source

Note: Version bump only for package @​typescript-eslint/parser

v5.59.8

Compare Source

Note: Version bump only for package @​typescript-eslint/parser

v5.59.7

Compare Source

Note: Version bump only for package @​typescript-eslint/parser

v5.59.6

Compare Source

Note: Version bump only for package @​typescript-eslint/parser

v5.59.5

Compare Source

Note: Version bump only for package @​typescript-eslint/parser

typescript-eslint/typescript-eslint (@​typescript-eslint/typescript-estree)

v5.59.9

Compare Source

Note: Version bump only for package @​typescript-eslint/typescript-estree

v5.59.8

Compare Source

Note: Version bump only for package @​typescript-eslint/typescript-estree

v5.59.7

Compare Source

Note: Version bump only for package @​typescript-eslint/typescript-estree

v5.59.6

Compare Source

Note: Version bump only for package @​typescript-eslint/typescript-estree

v5.59.5

Compare Source

Note: Version bump only for package @​typescript-eslint/typescript-estree

typescript-eslint/typescript-eslint (@​typescript-eslint/utils)

v5.59.9

Compare Source

Note: Version bump only for package @​typescript-eslint/utils

v5.59.8

Compare Source

Note: Version bump only for package @​typescript-eslint/utils

v5.59.7

Compare Source

Note: Version bump only for package @​typescript-eslint/utils

v5.59.6

Compare Source

Note: Version bump only for package @​typescript-eslint/utils

v5.59.5

Compare Source

Note: Version bump only for package @​typescript-eslint/utils

vitest-dev/vitest

v0.32.0

Compare Source

   🚨 Breaking Changes
  • Throw an error, if the module cannot be resolved  -  by @​sheremet-va in https://github.com/vitest-dev/vitest/issues/3307 (1ad63)
    • Vitest used to fall back to the original import when it could not resolve it to the file path or the virtual module. This leads to hard-to-find module graph mismatches if you had incorrect alias or relied on relative imports to be resolved to the project root (which is usual behavior in TypeScript) because the code accidentally "worked". With this release, Vitest will now throw an error if it cannot resolve the module - there are possible edge cases that are not covered yet, so if you have any problems with this, please open a separate issue with reproduction.
  • Improve globs  -  by @​nickmccurdy in https://github.com/vitest-dev/vitest/issues/3392 (19ecc)
    • Vitest now has glob patterns similar to Jest for better compatibility. It's possible that some files will be considered test files when previously they were not. For example, Vitest now considers test.js to be a test file. Also any file in __tests__ is now considered to be a test, not just files with test or spec suffix.
  • Add @vitest/coverage-v8 package  -  by @​AriPerkkio in https://github.com/vitest-dev/vitest/issues/3339 (82112)
    • Vitest now uses v8 code coverage directly for better performance. @vitest/coverage-c8 is deprecated as Vitest no longer uses c8 package for coverage output. It will not be updated anymore, and Vitest will fail in the next version if the user has c8 as their coverage provider. Please, install the new @vitest/coverage-v8 package if you previously used @vitest/coverage-c8.
  • mocker: Don't restore mock to the original if the module is automocked  -  by @​sheremet-va in https://github.com/vitest-dev/vitest/issues/3518 (c1004)
    • spy.mockRestore on auto-mocked named exports will no longer restore their implementation to the actual function. This behavior better matches what Jest does.
   🚀 Features
   🐞 Bug Fixes
    View changes on GitHub

v0.31.4

Compare Source

   🚀 Features
   🐞 Bug Fixes
    View changes on GitHub

v0.31.3

Compare Source

   🚀 Features
   🐞 Bug Fixes
    View changes on GitHub

v0.31.2

Compare Source

   🚀 Features
   🐞 Bug Fixes
    View changes on GitHub

v0.31.1

Compare Source

   🚀 Features
   🐞 Bug Fixes
    View changes on GitHub
motdotla/dotenv

v16.1.4

Compare Source

Added
  • Added .github/ to .npmignore #​747

v16.1.3

Compare Source

Removed
  • Removed browser keys for path, os, and crypto in package.json. These were set to false incorrectly as of 16.1. Instead, if using dotenv on the front-end make sure to include polyfills for path, os, and crypto. node-polyfill-webpack-plugin provides these.

v16.1.2

Compare Source

Changed
  • Exposed private function _configDotenv as configDotenv. #​744

v16.1.1

Compare Source

Added
  • Added type definition for decrypt function
Changed
  • Fixed {crypto: false} in packageJson.browser

v16.1.0

Compare Source

Added
  • Add populate convenience method #​733
  • Accept URL as path option #​720
  • Add dotenv to npm fund command
  • Spanish language README #​698
  • Add .env.vault support. 🎉 (#​730)

ℹ️ .env.vault extends the .env file format standard with a localized encrypted vault file. Package it securely with your production code deploys. It's cloud agnostic so that you can deploy your secrets anywhere – without risky third-party integrations. read more

Changed
  • Fixed "cannot resolve 'fs'" error on tools like Replit #​693
evanw/esbuild

v0.18.0

Compare Source

This release deliberately contains backwards-incompatible changes. To avoid automatically picking up releases like this, you should either be pinning the exact version of esbuild in your package.json file (recommended) or be using a version range syntax that only accepts patch upgrades such as ^0.17.0 or ~0.17.0. See npm's documentation about semver for more information.

The breaking changes in this release mainly focus on fixing some long-standing issues with esbuild's handling of tsconfig.json files. Here are all the changes in this release, in detail:

  • Add a way to try esbuild online (#​797)

    There is now a way to try esbuild live on esbuild's website without installing it: https://esbuild.github.io/try/. In addition to being able to more easily evaluate esbuild, this should also make it more efficient to generate esbuild bug reports. For example, you can use it to compare the behavior of different versions of esbuild on the same input. The state of the page is stored in the URL for easy sharing. Many thanks to @​hyrious for creating https://hyrious.me/esbuild-repl/, which was the main inspiration for this addition to esbuild's website.

    Two forms of build options are supported: either CLI-style (example) or JS-style (example). Both are converted into a JS object that's passed to esbuild's WebAssembly API. The CLI-style argument parser is a custom one that simulates shell quoting rules, and the JS-style argument parser is also custom and parses a superset of JSON (basically JSON5 + regular expressions). So argument parsing is an approximate simulation of what happens for real but hopefully it should be close enough.

  • Changes to esbuild's tsconfig.json support (#​3019):

    This release makes the following changes to esbuild's tsconfig.json support:

    • Using experimental decorators now requires "experimentalDecorators": true (#​104)

      Previously esbuild would always compile decorators in TypeScript code using TypeScript's experimental decorator transform. Now that standard JavaScript decorators are close to being finalized, esbuild will now require you to use "experimentalDecorators": true to do this. This new requirement makes it possible for esbuild to introduce a transform for standard JavaScript decorators in TypeScript code in the future. Such a transform has not been implemented yet, however.

    • TypeScript's target no longer affects esbuild's target (#​2628)

      Some people requested that esbuild support TypeScript's target setting, so support for it was added (in version 0.12.4). However, esbuild supports reading from multiple tsconfig.json files within a single build, which opens up the possibility that different files in the build have different language targets configured. There isn't really any reason to do this and it can lead to unexpected results. So with this release, the target setting in tsconfig.json will no longer affect esbuild's own target setting. You will have to use esbuild's own target setting instead (which is a single, global value).

    • TypeScript's jsx setting no longer causes esbuild to preserve JSX syntax (#​2634)

      TypeScript has a setting called jsx that controls how to transform JSX into JS. The tool-agnostic transform is called react, and the React-specific transform is called react-jsx (or react-jsxdev). There is also a setting called preserve which indicates JSX should be passed through untransformed. Previously people would run esbuild with "jsx": "preserve" in their tsconfig.json files and then be surprised when esbuild preserved their JSX. So with this release, esbuild will now ignore "jsx": "preserve" in tsconfig.json files. If you want to preserve JSX syntax with esbuild, you now have to use --jsx=preserve.

      Note: Some people have suggested that esbuild's equivalent jsx setting override the one in tsconfig.json. However, some projects need to legitimately have different files within the same build use different transforms (i.e. react vs. react-jsx) and having esbuild's global jsx setting override tsconfig.json would prevent this from working. This release ignores "jsx": "preserve" but still allows other jsx values in tsconfig.json files to override esbuild's global jsx setting to keep the ability for multiple files within the same build to use different transforms.

    • useDefineForClassFields behavior has changed (#​2584, #​2993)

      Class fields in TypeScript look like this (x is a class field):

      class Foo {
  x = 123
}

      TypeScript has legacy behavior that uses assignment semantics instead of define semantics for class fields when useDefineForClassFields is enabled (in which case class fields in TypeScript behave differently than they do in JavaScript, which is arguably "wrong").

      This legacy behavior exists because TypeScript added class fields to TypeScript before they were added to JavaScript. The TypeScript team decided to go with assignment semantics and shipped their implementation. Much later on TC39 decided to go with define semantics for class fields in JavaScript instead. This behaves differently if the base class has a setter with the same name:

      class Base {
  set x(_) {
    console.log('x:', _)
  }
}

// useDefineForClassFields: false
class AssignSemantics extends Base {
  constructor() {
    super()
    this.x = 123
  }
}

// useDefineForClassFields: true
class DefineSemantics extends Base {
  constructor() {
    super()
    Object.defineProperty(this, 'x', { value: 123 })
  }
}

console.log(
  new AssignSemantics().x, // Calls the setter
  new DefineSemantics().x // Doesn't call the setter
)

      When you run tsc, the value of useDefineForClassFields defaults to false when it's not specified and the target in tsconfig.json is present but earlier than ES2022. This sort of makes sense because the class field language feature was added in ES2022, so before ES2022 class fields didn't exist (and thus TypeScript's legacy behavior is active). However, TypeScript's target setting currently defaults to ES3 which unfortunately means that the useDefineForClassFields setting currently defaults to false (i.e. to "wrong"). In other words if you run tsc with all default settings, class fields will behave incorrectly.

      Previously esbuild tried to do what tsc did. That meant esbuild's version of useDefineForClassFields was false by default, and was also false if esbuild's --target= was present but earlier than es2022. However, TypeScript's legacy class field behavior is becoming increasingly irrelevant and people who expect class fields in TypeScript to work like they do in JavaScript are confused when they use esbuild with default settings. It's also confusing that the behavior of class fields would change if you changed the language target (even though that's exactly how TypeScript works).

      So with this release, esbuild will now only use the information in tsconfig.json to determine whether useDefineForClassFields is true or not. Specifically useDefineForClassFields will be respected if present, otherwise it will be false if target is present in tsconfig.json and is ES2021 or earlier, otherwise it will be true. Targets passed to esbuild's --target= setting will no longer affect useDefineForClassFields.

      Note that this means different directories in your build can have different values for this setting since esbuild allows different directories to have different tsconfig.json files within the same build. This should let you migrate your code one directory at a time without esbuild's --target= setting affecting the semantics of your code.

    • Add support for verbatimModuleSyntax from TypeScript 5.0

      TypeScript 5.0 added a new option called verbatimModuleSyntax that deprecates and replaces two older options, preserveValueImports and importsNotUsedAsValues. Setting verbatimModuleSyntax to true in tsconfig.json tells esbuild to not drop unused import statements. Specifically esbuild now treats "verbatimModuleSyntax": true as if you had specified both "preserveValueImports": true and "importsNotUsedAsValues": "preserve".

    • Add multiple inheritance for tsconfig.json from TypeScript 5.0

      TypeScript 5.0 now allows multiple inheritance for tsconfig.json files. You can now pass an array of filenames via the extends parameter and your tsconfig.json will start off containing properties from all of those configuration files, in order. This release of esbuild adds support for this new TypeScript feature.

    • Remove support for moduleSuffixes (#​2395)

      The community has requested that esbuild remove support for TypeScript's moduleSuffixes feature, so it has been removed in this release. Instead you can use esbuild's --resolve-extensions= feature to select which module suffix you want to build with.

    • Apply --tsconfig= overrides to stdin and virtual files (#​385, #​2543)

      When you override esbuild's automatic tsconfig.json file detection with --tsconfig= to pass a specific tsconfig.json file, esbuild previously didn't apply these settings to source code passed via the stdin API option or to TypeScript files from plugins that weren't in the file namespace. This release changes esbuild's behavior so that settings from tsconfig.json also apply to these source code files as well.

    • Support --tsconfig-raw= in build API calls (#​943, #​2440)

      Previously if you wanted to override esbuild's automatic tsconfig.json file detection, you had to create a new tsconfig.json file and pass the file name to esbuild via the --tsconfig= flag. With this release, you can now optionally use --tsconfig-raw= instead to pass the contents of tsconfig.json to esbuild directly instead of passing the file name. For example, you can now use --tsconfig-raw={"compilerOptions":{"experimentalDecorators":true}} to enable TypeScript experimental decorators directly using a command-line flag (assuming you escape the quotes correctly using your current shell's quoting rules). The --tsconfig-raw= flag previously only worked with transform API calls but with this release, it now works with build API calls too.

    • Ignore all tsconfig.json files in node_modules ([#​276](https://togithub.com/evanw/e

Configuration

📅 Schedule: Branch creation - "before 5am on saturday" in timezone America/New_York, Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, 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, check this box

This PR has been generated by Mend Renovate. View repository job log here.

@renovate renovate bot force-pushed the renovate/minors-and-patches branch 7 times, most recently from e308d9c to 4779807 Compare June 9, 2023 18:30
@renovate renovate bot force-pushed the renovate/minors-and-patches branch from 4779807 to 854d66d Compare June 9, 2023 22:17
@renovate
Copy link
Contributor Author

renovate bot commented Jun 9, 2023

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.

@asdfjkalsdfla asdfjkalsdfla merged commit 7f3bb8a into main Jun 9, 2023
@asdfjkalsdfla asdfjkalsdfla deleted the renovate/minors-and-patches branch June 9, 2023 23:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@asdfjkalsdfla