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

fix(deps): update auto merge on patch or minor #1778

Merged
merged 2 commits into from
Oct 30, 2024
Merged

fix(deps): update auto merge on patch or minor #1778

merged 2 commits into from
Oct 30, 2024

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Oct 29, 2024 •
edited
Loading

This PR contains the following updates:

Package Change Age Adoption Passing Confidence Type Update
@apollo/server (source) ^4.11.0 -> ^4.11.2 age adoption passing confidence dependencies patch
@mui/icons-material (source) 6.1.5 -> 6.1.6 age adoption passing confidence dependencies patch
@mui/material (source) 6.1.5 -> 6.1.6 age adoption passing confidence dependencies patch
@typescript-eslint/eslint-plugin (source) 8.12.1 -> 8.12.2 age adoption passing confidence devDependencies patch
@typescript-eslint/parser (source) 8.12.1 -> 8.12.2 age adoption passing confidence devDependencies patch
node (source) 22 -> 22.11.0 age adoption passing confidence minor
sass 1.80.4 -> 1.80.5 age adoption passing confidence devDependencies patch
typescript-eslint (source) 8.12.1 -> 8.12.2 age adoption passing confidence devDependencies patch

Release Notes

apollographql/apollo-server (@​apollo/server)

v4.11.2

Compare Source

(No change; there is a change to the @apollo/server-integration-testsuite used to test integrations, and the two packages always have matching versions.)

v4.11.1

Compare Source

Patch Changes

  • #​7952 bb81b2c Thanks @​glasser! - Upgrade dependencies so that automated scans don't detect a vulnerability.

    @apollo/server depends on express which depends on cookie. Versions of express older than v4.21.1 depend on a version of cookie vulnerable to CVE-2024-47764. Users of older express versions who call res.cookie() or res.clearCookie() may be vulnerable to this issue.

    However, Apollo Server does not call this function directly, and it does not expose any object to user code that allows TypeScript users to call this function without an unsafe cast.

    The only way that this direct dependency can cause a vulnerability for users of Apollo Server is if you call startStandaloneServer with a context function that calls Express-specific methods such as res.cookie() or res.clearCookies() on the response object, which is a violation of the TypeScript types provided by startStandaloneServer (which only promise that the response object is a core Node.js http.ServerResponse rather than the Express-specific subclass). So this vulnerability can only affect Apollo Server users who use unsafe JavaScript or unsafe as typecasts in TypeScript.

    However, this upgrade will at least prevent vulnerability scanners from alerting you to this dependency, and we encourage all Express users to upgrade their project's own express dependency to v4.21.1 or newer.

mui/material-ui (@​mui/icons-material)

v6.1.6

Compare Source

Oct 30, 2024

A big thanks to the 13 contributors who made this release possible.

@mui/[email protected]
@mui/[email protected]
@mui/[email protected]
@mui/[email protected]
@mui/[email protected]
Docs
Core

All contributors of this release in alphabetical order: @​aarongarciah, @​blackcow1987, @​DiegoAndai, @​jimmycallin, @​joshkel, @​mnajdova, @​navedqb, @​nphmuller, @​o-alexandrov, @​oliviertassinari, @​prakhargupta1, @​sai6855, @​siriwatknp

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

v8.12.2

Compare Source

🩹 Fixes
  • eslint-plugin: [switch-exhaustiveness-check] invert considerDefaultExhaustiveForUnions (#​10223)
❤️ Thank You

You can read about our versioning strategy and releases on our website.

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

v8.12.2

Compare Source

This was a version bump only for parser to align it with other projects, there were no code changes.

You can read about our versioning strategy and releases on our website.

nodejs/node (node)

v22.11.0

Compare Source

v22.10.0: 2024-10-16, Version 22.10.0 (Current), @​aduh95

Compare Source

Notable Changes
New "module-sync" exports condition

This release introduces a "module-sync" exports condition that's enabled when
require(esm) is enabled, so packages can supply a synchronous ES module to the
Node.js module loader, no matter if it's being required or imported. This is
similar to the "module" condition that bundlers have been using to support
require(esm) in Node.js, and allows dual-package authors to opt into ESM-first
only on newer versions of Node.js that supports require(esm) to avoid the
dual-package hazard.

{
  "type": "module",
  "exports": {
    "node": {
      // On new version of Node.js, both require() and import get
      // the ESM version
      "module-sync": "./index.js",
      // On older version of Node.js, where "module-sync" and require(esm) are
      // not supported, use the CJS version to avoid dual-package hazard.
      // When package authors think it's time to drop support for older versions of
      // Node.js, they can remove the exports conditions and just use "main": "index.js".
      "default": "./dist/index.cjs"
    },
    // On any other environment, use the ESM version.
    "default": "./index.js"
  }
}

Or if the package is only meant to be run on Node.js and wants to fallback to
CJS on older versions that don't have require(esm):

{
  "type": "module",
  "exports": {
    // On new version of Node.js, both require() and import get the ESM version
    "module-sync": "./index.js",
    // On older version of Node.js, where "module-sync" and require(esm) are
    // not supported, use the CJS version to avoid dual-package hazard.
    // When package authors think it's time to drop support for older versions of
    // Node.js, they can remove the exports conditions and just use "main": "index.js".
    "default": "./dist/index.cjs"
  }
}

For package authors: this only serves as a feature-detection mechanism for
packages that wish to support both CJS and ESM users during the period when some
active Node.js LTS versions support require(esm) while some older ones don't.
When all active Node.js LTS lines support require(esm), packages can simplify
their distributions by bumping the major version, dropping their CJS exports,
and removing the module-sync exports condition (with only main or default
targetting the ESM exports). If the package needs to support both bundlers and
being run unbundled on Node.js during the transition period, use both
module-sync and module and point them to the same ESM file. If the package
already doesn't want to support older versions of Node.js that doesn't support
require(esm), don't use this export condition.

For bundlers/tools: they should avoid implementing this stop-gap condition.
Most existing bundlers implement the de-facto bundler standard
module
exports condition, and that should be enough to support users who want to bundle
ESM from CJS consumers. Users who want both bundlers and Node.js to recognize
the ESM exports can use both module/module-sync conditions during the
transition period, and can drop module-sync+module when they no longer need
to support older versions of Node.js. If tools do want to support this
condition, it's recommended to make the resolution rules in the graph pointed by
this condition match the Node.js native ESM rules to avoid divergence.

We ended up implementing a condition with a different name instead of reusing
"module", because existing code in the ecosystem using the "module"
condition sometimes also expect the module resolution for these ESM files to
work in CJS style, which is supported by bundlers, but the native Node.js loader
has intentionally made ESM resolution different from CJS resolution (e.g.
forbidding import './noext' or import './directory'), so it would be
breaking to implement a "module" condition without implementing the forbidden
ESM resolution rules. For now, this just implements a new condition as
semver-minor so it can be backported to older LTS.

Contributed by Joyee Cheung in #​54648.

node --run is now stable

This CLI flag runs a specified command from a package.json's "scripts" object.

For the following package.json:

{
  "scripts": {
    "test": "node --test-reporter junit --test ./test"
  }
}

You can run node --run test and that would start the test suite.

Contributed by Yagiz Nizipli in #​53763.

Other notable changes
  • [f0b441230a] - (SEMVER-MINOR) crypto: add KeyObject.prototype.toCryptoKey (Filip Skokan) #​55262
  • [349d2ed07b] - (SEMVER-MINOR) crypto: add Date fields for validTo and validFrom (Andrew Moon) #​54159
  • [bebc95ed58] - doc: add abmusse to collaborators (Abdirahim Musse) #​55086
  • [914db60159] - (SEMVER-MINOR) http2: expose nghttp2_option_set_stream_reset_rate_limit as an option (Maël Nison) #​54875
  • [f7c3b03759] - (SEMVER-MINOR) lib: propagate aborted state to dependent signals before firing events (jazelly) #​54826
  • [32261fc98a] - (SEMVER-MINOR) module: support loading entrypoint as url (RedYetiDev) #​54933
  • [06957ff355] - (SEMVER-MINOR) module: implement flushCompileCache() (Joyee Cheung) #​54971
  • [2dcf70c347] - (SEMVER-MINOR) module: throw when invalid argument is passed to enableCompileCache() (Joyee Cheung) #​54971
  • [f9b19d7c44] - (SEMVER-MINOR) module: write compile cache to temporary file and then rename it (Joyee Cheung) #​54971
  • [e95163b170] - (SEMVER-MINOR) process: add process.features.require_module (Joyee Cheung) #​55241
  • [4050f68e5d] - (SEMVER-MINOR) process: add process.features.typescript (Aviv Keller) #​54295
  • [86f7cb802d] - (SEMVER-MINOR) test_runner: support custom arguments in run() (Aviv Keller) #​55126
  • [b62f2f8259] - (SEMVER-MINOR) test_runner: add 'test:summary' event (Colin Ihrig) #​54851
  • [d7c708aec5] - (SEMVER-MINOR) test_runner: add support for coverage via run() (Chemi Atlow) #​53937
  • [5fda4a1498] - (SEMVER-MINOR) worker: add markAsUncloneable api (Jason Zhang) #​55234
Commits

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.

👻 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 was generated by Mend Renovate. View the repository job log.

@renovate renovate bot force-pushed the renovate/auto-merge-on-patch-or-minor branch from 70461de to f386764 Compare October 29, 2024 17:29
@renovate renovate bot changed the title chore(deps): update auto merge on patch or minor to v8.12.2 chore(deps): update auto merge on patch or minor Oct 29, 2024
@renovate renovate bot force-pushed the renovate/auto-merge-on-patch-or-minor branch from f386764 to 0452aaf Compare October 29, 2024 19:30
@renovate renovate bot changed the title chore(deps): update auto merge on patch or minor fix(deps): update auto merge on patch or minor Oct 29, 2024
@renovate renovate bot force-pushed the renovate/auto-merge-on-patch-or-minor branch 4 times, most recently from d448474 to 8c46d6d Compare October 30, 2024 01:29
@renovate renovate bot force-pushed the renovate/auto-merge-on-patch-or-minor branch from 8c46d6d to e1f9cd2 Compare October 30, 2024 13:32
@notaphplover notaphplover merged commit 13ec489 into master Oct 30, 2024
6 checks passed
@notaphplover notaphplover deleted the renovate/auto-merge-on-patch-or-minor branch October 30, 2024 21:19
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
@notaphplover