Update dependency peggy to v4 (main) by elastic-renovate-prod[bot] · Pull Request #212280 · elastic/kibana

elastic-renovate-prod · 2025-02-24T16:42:49Z

This PR contains the following updates:

Package	Type	Update	Change
peggy (source)	devDependencies	major	`^1.2.0` -> `^4.2.0`

Release Notes

peggyjs/peggy (peggy)

`v4.2.0`

Compare Source

Released: 2024-11-19

New features

#568 Upgrading to TypeScript 5.6 allowed for generating parser.d.ts, which should may help people that use Peggy programmatically in nonstandard ways.

Bug fixes

#567 Load config files and plugins correctly on Windows by using file: URIs in import().

Documentation

#566 Slight tweaks to document generation.

`v4.1.1`

Compare Source

v4.1.0 did not actually get published due to a workflow issue that should
be sorted out now.

New features

#477 Option to output .d.ts files next to .js from CLI.
#530 Allow es6 plugins from CLI
#532 Allow es6 options files from the CLI

Bug fixes

#531 Clean up rollup hacks from CLI code.
#514 Allow execution of the peggy binary on Windows by handling node runtime flags manually, executing a sub-instance of node to actually run peggy.
#538 Fixed error in TS types for peg$maxFailExpected and peg$maxFailPos.
#551 Moved to package-extract instead of a custom script for version file generation.

`v4.0.3`

Compare Source

Released: 2024-06-19

New features

#509 Add and implement ES6 export button

Bug fixes

#493 Allow use of an empty
array, null, or undefined as allowedStartRules option
#505 Fix vscode-eslint settings
to work with eslint flat config
#507 Remove stray semicolon in CSS
#508 Fix broken text input in
web version
#512 Add "StartRules" to peg.d.ts
#513 Allow whitespace between
plucked word and its pattern.
#520 Grammar with token "constructor" fails to generate
#522 Switched from puppeteer
to playwright for web tests, and added them to CI.

Documentation

#506 Added END OF INPUT (!.).

`v4.0.2`

Compare Source

Released: 2024-02-26

Bug fixes

#490 Throw error when imports are used in unsupported formats. Supported formats are now only "es" and "commonjs".
#494 Updated docs to make --allowedRules * more clear
#495 from-mem inadvertantly
made the minimum supported node version v20.8. Updated to latest from-mem.

`v4.0.1`

Compare Source

Released: 2024-02-23

Bug fixes

#478 Add "npx" to some doc
examples.
#479
Refactor cli/fromMem.js into separate project
from-mem.
#481 Add CLI test for
--library
#483 fix errors in
typescript file.

`v4.0.0`

Compare Source

Released: 2024-02-13

Major Changes

#379 Fix infinite recursion
issue by moving reportInfiniteRecursion to the new prepare pass, and having
it fail after finding the first issue. This will require plugin authors
to ensure that reportInfiniteRecursion is in the new pass correctly.
#417 BREAKING: change to AST to
allow topLevelInitializer and initializer to be arrays, in support of
multi-file inputs. This will require plugin updates. The CLI and API now
take multiple files as input, where the first file is your main library, and
subsequent files consist of a library of other rules. The CLI can take file
names of the form npm:<package-name>/<filename> to load library rules from
an NPM package that is installed relative to the previous non-npm file name,
or to the current working directory if this is the first file name.
#420 BREAKING: Node v16+ is now
required for running the CLI or using Peggy as a library. Generated code
still targets older runtimes.
#456 BREAKING: Allow imports
from external compiled grammars inside a source grammar, using import {rule} from "external.js". Note that this syntax will generate either
import or require in the JavaScript output, depending on the value of
the format parameter. This will need explicit support from
plugins, with a few new AST node types and a few visitor changes.
#463 Drop support for
Internet Explorer. Move to eslint flat configs in order to lint minimized
browser code for compatibility with
defaults, maintained node versions, not op_mini all.

Minor Changes

#400 Use @generated in generated
code
#404 Add support for -w/--watch
to the command line interface.
#415 Added browser key to package.json, pointing to Webpack output.
#420 Updated dependencies to
avoid audit warnings.
#425 Add a pass to simplify single-character choices
#427 Avoid double extraction of
substrings in various MATCH_ bytecodes
#430 Make generate-js.js ts clean
#432 Add peggy.code-workspace
#435 Setup tsconfig to detect use of library functions from es6 or later
#436 Get rid of tsd
#437 Better type checking for visitor
#438 Make test build deterministic
#439 Make peg$computePosDetails a little faster
#440 Create directories for
output and source-map if they do not exist, rather than erroring.
#446 Add a right-associative ExponentiationExpression rule (operator **) to javascript.pegjs example grammar.
#451 Make stack.js ts clean
#452 Fixes to prepare generate-bytecode.js for ts-check
#453 Make generate-bytecode.js ts-clean
#460 Allow -t and -T testing
from the CLI with --format es.

Bug Fixes

#405 Doc example doesn't correspond to code example. From @hildjj
#415 Make docs match reality with import.
#426 Fix typo in XML example.
#434 Fixed bad example in docs.
#445 Fix indentation in examples/javascript.pegjs.
#450 Fixed misleading documentation.
#466 Add docs for developers.

`v3.0.2`

Compare Source

Released: 2023-03-21

Minor Changes

#392 Removed the --optimize
command line argument, which has been invalid since v1.2. From @hildjj.

Bug Fixes

#371 Error using online Peggy - "Can't find variable: util". From @hildjj.
#374 CLI throws exception
on grammar errors. From @hildjj
#381 Repetitions with code blocks
for min or max not handling non-integer returns correctly. From @hildjj.
#382 Update grammarSource
documentation. From @AndrewRayCode.
#384 Improve the error.format()
documentation. From @AndrewRayCode.
#386 Ensure '*' as
allowed-start-rule is documented for CLI. From @hildjj.

`v3.0.1`

Compare Source

Released: 2022-03-05

Minor Changes

#329 Allow plugin options in
generate. This change loosens type checking strictness to allow for options
unknown to Peggy, but used by plugins such as ts-pegjs. From @hildjj.

Bug Fixes

#329 Allow type definition for ParserBuildOptions to include plugin options. From @hildjj.
#346 Allow extra semicolons
between rules. From @hildjj.
#347 Disallow '$' as an initial
character in identifiers. This is not a breaking change because no grammar
could have successfully used these in the past. From @hildjj.
#354 Various minor nits in the
docs, including indentation and ensuring that the CNAME file is correct.
#357 Fix infinite recursion
possibility in repetition delimeters. From @hildjj and @Mingun.
#359 Do not treat as many
words as reserved. Clarify the documentation about identifiers. Ensure
that it is more clear that the target language being generated determines
what words are reserved. Clarify that reserved word checking is only
done for labels. From @nene.
#364 Fix passing an incorrect
external label to the expression inside the repeated node. From @Mingun.

`v3.0.0`

Compare Source

Released: 2023-02-21

Major Changes

#280 Add inline examples to
the documentation, from @hildjj
#240 Generate SourceNodes for
bytecode, from @hildjj
#338 BREAKING CHANGE. Update
dependencies, causing minimum supported version of node.js to move to 14.
Generated grammar source should still work on older node versions and some
older browsers, but testing is currently manual for those. from @hildjj
#291: Add support for
repetition operator expression|min .. max, delimiter|, from @Mingun
#339: BREAKING CHANGE. Updated
the list of JavaScript reserved words. This will break existing grammars
that use any of the new words in their rule or label names. from @hildjj

Important information for plug-in authors: PR #291 added 4 new opcodes to the bytecode:

IF_LT
IF_GE
IF_LT_DYNAMIC
IF_GE_DYNAMIC

and added a new AST node and a visitor method repeated. Do not forget to update your plug-ins.

Important information for grammar authors: the following words, which used to
be valid identifiers for rules and labels, are now treated as JavaScript
reserved words, and will cause errors at compile time if you are using them:

abstract
arguments
as
async
boolean
byte
char
double
eval
final
float
from
get
goto
int
long
native
of
set
short
synchronized
throws
transient
volatile

Minor Changes

#274 "*" is now a valid allowedStartRule, which means all rules are allowed, from @hildjj
#229 new CLI option
-S <rule> or --start-rule <rule> to specify the start rule when testing,
from @hildjj
#236 Website: show line numbers
in parser input textarea, from @Mingun
#280 new output type
source-with-inline-map, which generates source text with an inline map,
from @hildjj
#285 Require that a non-empty
string be given as a grammarSource if you are generating a source map, from
@hildjj
#206: New output type ast and
an --ast flag for the CLI to get an internal grammar AST for investigation
(can be useful for plugin writers), from @Mingun
#294 Website: show errors in the
editors, from @Mingun
#297 Website: add Discord widget,
from @hildjj
#299 Add example grammar for a
SemVer.org semantic version string, from @dselman
#307 Allow grammars to have
relative offsets into their source files (e.g. if embedded in another doc),
from @hildjj.
#308 Add support for reading test
data from stdin using -T -, from @hildjj.
#313 Create the website using
eleventy, from @camcherry

Bug Fixes

#283 Fix incorrect type
information for DiagnosticCallback, from @hildjj
#287 Allow large outputs
to be received without blocking on the CLI tests, from @hildjj

`v2.0.1`

Compare Source

Released: 2022-01-01

Major Changes

None

Minor Changes

#261: Remove documentation from
README.md, instead linking to the HTML documentation. HTML documentation on
https://peggyjs.org is now served from the docs branch, so that it won't
update as we change the main branch. main must be merged onto docs as
a part of the release process going forward.
#266: Expose the private
field problems in the Session class, from @hildjj.

Bug Fixes

#263: Broken link to unpkg.
This bug was a symptom of a relatively bad issue in the 2.0.0 release, where
the web version of peggy was put in the wrong place, and therefore not
tested in the release process. From @hildjj.

`v2.0.0`

Compare Source

Released: 2022-05-28

Major Changes

#163: Add support for
generating source maps, from @Mingun
#160: Introduce an API for
reporting errors, warnings and information messages from passes. New API
allows reporting several diagnostics at once with intermediate results
checking after each compilation stage, from @Mingun
#218: Add a sourceMappingURL
to the generated code, from @hildjj
#248: Remove support for
Node.js version 10. When updating dependencies, too many of the tools we
use no longer work on the Node 10, which went out of security maintenance
more than a year ago. Added support for Node.js version 18, from @hildjj
#251: Make commander and
source-map-generator full dependencies. These are not needed for the
pre-packaged web build, but will be used by Node or people that are doing
their own packaging for the web, from @hildjj

Minor Changes

#167: New CLI, from @hildjj
- Backward compatible with the previous
- New -t/--test and -T/--testfile flags to directly test the generated grammar
#169: Expose string escape
functions, stringEscape() and regexpClassEscape(), from @hildjj
#175: Check allowedStartRules
for validity, from @hildjj
#185: Updated eslint rules,
from @hildjj
#196: Add example grammars for
XML and source-mapping, from @hildjj
#204: Increase coverage for the
tests, from @Mingun
#210: Refactor CLI testing,
from @hildjj

Bug fixes

#164: Fix some errors in the
typescript definitions, from @Mingun
#170: Add
missing argument in function call, from @darlanalves
#182: Fix typo in
documentation, from @zargold
#197: Fix a regression of
redundant commas in the character classes in the error messages, introduced
in fad4ab7, from @Mingun
#198: Make all build scripts
run on Windows, from @hildjj
#199: Test web version locally,
using puppeteer, from @hildjj
#211:Command-line -t requires
from wrong directory, from @hildjj
#212: Parse errors with zero
length give badly-formatted errors, from @hildjj
#214: Failing tests don't
format errors
#216: Fix typescript
definition of SyntaxError, from @cmfcmf
#220: Fix rollup warnings,
from @hildjj
#285: Work around source-map
bug by throwing an exception if no grammarSource is given when generating
source maps, from @hildjj.

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.

davismcphee · 2025-02-24T17:06:08Z

/ci

davismcphee · 2025-02-24T19:27:18Z

/ci

elasticmachine · 2025-02-24T19:27:48Z

Pinging @elastic/kibana-visualizations (Team:Visualizations)

elasticmachine · 2025-02-24T19:27:48Z

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

davismcphee · 2025-02-24T21:21:11Z

@lukasolson @markov00 This is a big version bump, but other than some minor test failures due to error formatting changes, it passes CI. Any idea if merging this would be a bad idea, or do we think it makes sense?

kertal · 2025-03-03T16:53:48Z

/ci

elastic-renovate-prod · 2025-03-03T17:21:18Z

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.

kertal · 2025-03-11T09:09:19Z

/ci

lukasolson

Checked it out locally to make sure the build steps are still working properly when we make changes to the grammar.peggy files and it seems as if they are.

davismcphee · 2025-03-11T19:04:21Z

/ci

davismcphee · 2025-03-11T19:05:20Z

Just kicked off another CI build for this since it doesn't happen automatically when merging main. @lukasolson would you do the honours of merging once it passes? 🙏

elasticmachine · 2025-03-11T20:59:01Z

💚 Build Succeeded

Buildkite Build
Commit: b3b3828

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`canvas`	1001.1KB	1001.4KB	+283.0B
`expressions`	30.2KB	30.2KB	+22.0B
`lens`	1.5MB	1.5MB	+283.0B
`presentationUtil`	86.8KB	87.0KB	+261.0B
`visTypeTimelion`	39.6KB	39.8KB	+243.0B
total			+1.1KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
`expressions`	92.4KB	92.6KB	+261.0B
`kbnUiSharedDeps-srcJs`	3.6MB	3.6MB	+839.0B
total			+1.1KB

History

💚 Build #282593 succeeded eebf239
💔 Build #280421 failed d592270
💚 Build #278962 succeeded 4b66868a1e3368bb9c801a242ede6c610fb7c2b5
💔 Build #278926 failed cfbe50fc63ba91e1a1263c8c47bbb195c4e8de07

cc @lukasolson @davismcphee

kibanamachine · 2025-03-21T00:48:41Z

Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync.

kibanamachine · 2025-03-24T01:48:42Z

Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync.

kibanamachine · 2025-03-25T02:48:34Z

Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync.

# Backport This will backport the following commits from `main` to `9.0`: - [Update dependency peggy to v4 (main) (#212280)](#212280) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>

kibanamachine · 2025-03-26T02:48:39Z

Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync.

nickofthyme · 2025-03-27T00:14:48Z

I don't think this needs to be backported. Renovate has backport:all-open as default backport for some reason. Replaced with backport:skip.

azasypkin · 2025-03-28T16:42:29Z

I don't think this needs to be backported. Renovate has backport:all-open as default backport for some reason. Replaced with backport:skip.

@nickofthyme, is there any reason we don't want to backport to at least 9.0 and 8.x?

Missing backports that touch yarn.lock make other backports more complicated (e.g., #216284 (comment)), as they almost always will require manual conflict resolution. Plus, we'll have to live with 8.x for a number of years, and old packages might have bugs (and vulnerabilities) that we'll need to address - but it'd be harder to do later.

That's all to say, if there aren't significant risks in backporting dependency upgrades, we should generally try to backport them to as many old but supported branches as possible (which is why backport:all-open is the default).

nickofthyme · 2025-03-28T17:37:43Z

@azasypkin In this case I have no clue what peggy touches and if a backport is needed. It doesn't seem like there is a need to do so here especially not to all-open.

I don't believe backport:all-open is the best default, that rational only applies in cases of security patches.

It would be more sensible to me if the default was all active branches (i.e. 8.x), especially when doing major version upgrades.

That's all to say, if there aren't significant risks in backporting dependency upgrades, we should generally try to backport them to as many old but supported branches as possible (which is why backport:all-open is the default).

I would agree with this for patches and security fixes, everything else is all risk and little reward.

markov00 · 2025-03-28T18:11:51Z

Missing backports that touch yarn.lock make other backports more complicated (e.g., #216284 (comment)), as they almost always will require manual conflict resolution.

@azasypkin I believe we should never manually resolve conflicts on a yarn.lock, I always pull that branch, reset the yarn.lock and update it via yarn kbn bootstrap this correct the file without mistakes.

azasypkin · 2025-03-28T18:21:12Z

@azasypkin In this case I have no clue what peggy touches

Do you mean that your team doesn't actually use peggy, and the ownership defined in

kibana/renovate.json

Lines 3660 to 3678 in 6e5fe31

    
           { 
        
             "groupName": "Peggy", 
        
             "matchDepNames": [ 
        
               "peggy" 
        
             ], 
        
             "reviewers": [ 
        
               "team:kibana-visualizations", 
        
               "team:kibana-data-discovery" 
        
             ], 
        
             "matchBaseBranches": [ 
        
               "main" 
        
             ], 
        
             "labels": [ 
        
               "release_note:skip", 
        
               "backport:all-open" 
        
             ], 
        
             "minimumReleaseAge": "7 days", 
        
             "enabled": true 
        
           },

should be transferred to another team that actually uses it, or…?

I would agree with this for patches and security fixes, everything else is all risk and little reward.

That's what I'm trying to figure out since I'm not an owner of this dependency and don't have any context. Were there any breaking changes in peggy upgrades that you feel are risky, or do you generally lack confidence in the quality of peggy updates? I see it's a part of devDependencies that's why I'm trying to understand the risk you might be alluding to.

I'm asking because we're also working on ensuring that Kibana predominantly uses dependencies that are "healthy" and that we have enough confidence in them.

It would be more sensible to me if the default was all active branches (i.e. 8.x), especially when doing major version upgrades.

What do you mean by active? Today, IIRC, we define active branches as those we're planning to release from - meaning 8.17, 8.18, 8.19 (8.x), 9.0, and 9.1 (main). That's exactly what all-open covers. The only exception is 7.17, which we don't need to touch unless there's a strong reason, and it's easy to reject a backport to it if unnecessary.

The goal is to keep all branches that our users rely on in production with up to date dependencies (for all Elastic products, not just Kibana). If there's a good reason to exclude a particular dependency upgrade from all-open, that's fine, but it should be a concise and explicit decision with a clear rationale.

@azasypkin I believe we should never manually resolve conflicts on a yarn.lock, I always pull that branch, reset the yarn.lock and update it via yarn kbn bootstrap this correct the file without mistakes.

Correct, that's what I mean by a manual backport (which also requires an additional review), as opposed to a backport fully handled by the automation (based on backport tool) when there are no conflicts in yarn.lock that require manual conflict resolution.

azasypkin · 2025-03-28T18:33:00Z

(FWIW, this particular peggy upgrade isn't a huge deal — it's just a great excuse to check if we're all aligned on dependency backport policies and whether there are any issues or burdens with maintaining dependencies that are slowing you down or causing confusion. That way, we can see if there's anything we can fix, whether it's alignment, tooling, or something else 🙂)

nickofthyme · 2025-03-28T19:03:12Z

Do you mean that your team doesn't actually use peggy, and the ownership defined in

No it is the correct team but I personally am not intimately familiar with peggy usage.

Were there any breaking changes in peggy upgrades that you feel are risky, or do you generally lack confidence in the quality of peggy updates? I see it's a part of devDependencies that's why I'm trying to understand the risk you might be alluding to.

I think this is the opposite mindset -- I would reverse this statement to ask "what is the benefit to backporting this dependency?" Regardless of the type of dependency.

I didn't realize it was a part of devDependencies but it looks to be a webpack file loader for timelion 🦁 . But even as a devDependency it's also a build dependency which could cause unknown issues. In some other case it could be that it is truly dev dependency (no unknown impact) and would be convenient to have on 8.x for some reason, I think that's perfectly fine.

I'm asking because we're also working on ensuring that Kibana predominantly uses dependencies that are "healthy" and that we have enough confidence in them.

I love this idea but I don't think that means backporting all upgrades to all open versions.

What do you mean by active?

Sorry idk the specific internal naming. By active I was meaning the branches currently accepting features. Right now this would be 8.x and main, everything else is open, per se, but it's not accepting features.

[This] isn't a huge deal — it's just a great excuse to check if we're all aligned on dependency

Exactly! I think we should come to an agreement across kibana/elastic about the best approach.

The main thing that scares me is updating dependencies for the sack of updating them, not knowing what regressions are hidden in that simple act.

Take #216284 for example, we are upgrading vega to the latest patch version. I think this is ok for active branches still accepting features because these branches will have more thorough manual testing before being released. But we are backporting this to 8.17 and 8.18 which work fine as is and have no reason to upgrade this dependency. There's no security benefit or known kibana bug fix. This approach could easily lead to regressions, especially when talking about minor or major upgrades.

This is simply my take and I in the end I think it's a balance and a case-by-case decision. But having a formal document for our approach and general guidelines would really nice, if it doesn't exist already!

thomasneirynck · 2025-03-28T19:44:16Z

I did a quick search and find these two references:

In

kibana/src/platform/packages/private/kbn-tinymath/src/index.js

Line 13 in a382d35

const { parse: parseFn } = require('./grammar.peggy');
kibana/src/dev/build/tasks/build_packages_task.ts

Line 14 in 3b2ab7b

import * as Peggy from '@kbn/peggy';

not sure how that tinymath actually ends up using this.

wrt where to backport:

is there any reason we don't want to backport to at least 8.18/9.0 and 8.x?

I agree I don't see much reason not to do this. There is some lead time still, and we will benefit from having the code aligned.

If we are hesitant due to the "opaqueness" of this change (and I don't know how significant this change is at all), I do agree we could skip backport to 8.17. I'd only do this if there is a particular reason this change looks "dangerous".

The main thing that scares me is updating dependencies for the sack of updating them, not knowing what regressions are hidden in that simple act.

Yes, but the paradigm is shifting: with Serverless, Kibana is released from main. When we are withholding backports to already released branches out of safety-concerns, we are not showing that concern to our Serverless users. Safety will have to come from being confident in our automated testing, not by preventing code changes.

everything else is open, per se, but it's not accepting features.

Yes. This is annoying edge case imho. This is neither a feature nor a bug fix. It's an automated patch. This leans more towards bug fix imho.

But having a formal document for our approach and general guidelines would really nice, if it doesn't exist already!

Agreed that this is an edge-case and can be clarified. afaict, we don't have clear guidelines for these renovate version bumps. I can follow up on this to see if can get broader clarification on "chores" like this.

Recommendation:

Trust the process and backport to all open branches. What is the worst case? A bug is introduced that will require a rollback on all branches, iso of only the buggy branches. The best case is that code remains neatly aligned.
if we are too uncertain (and this is for the team to decide), backport this to 8.x only but motivate why this upgrade in particular seems so risky. Is there missing test coverage for the functionality? Over time, we will better start to understand these test gaps, and close them.

lukasolson · 2025-03-29T00:35:13Z

This has already been backported:

I've closed the other backport PRs.

azasypkin · 2025-03-31T14:34:15Z

Yes, but the paradigm is shifting: with Serverless, Kibana is released from main. When we are withholding backports to already released branches out of safety-concerns, we are not showing that concern to our Serverless users. Safety will have to come from being confident in our automated testing, not by preventing code changes.

Thanks, @thomasneirynck, that's a very good point and one of the main reasons we strive to keep our dependencies up to date and limit their growth. Whatever we merge on Thursday might reach users as early as Tuesday, and it's unlikely that manual verification will catch issues before production is impacted. That's why we should rely on thorough reviews of dependency upgrades (including reading release notes) and automated testing.

Depending on the level of confidence in a particular dependency, we might need to tweak minimumReleaseAge to upgrade only when it's considered stable enough.

Yes. This is annoying edge case imho. This is neither a feature nor a bug fix. It's an automated patch. This leans more towards bug fix imho.

++, it's regular maintenance that's closer to bug fixes than features, as long as we don't make interfaces of third-party dependencies part of our own public interfaces (e.g., for vega, we wouldn't backport any major version bumps in a Kibana patch release without a strong need).

Agreed that this is an edge-case and can be clarified. afaict, we don't have clear guidelines for these renovate version bumps. I can follow up on this to see if can get broader clarification on "chores" like this.

Yeah, we can definitely add more details to our Managing third-party dependencies internal development docs regarding the suggested backport approach and the reasoning behind it.

Recommendation:

Agreed on both, @thomasneirynck, I'll take an action item for our team to codify these in our existing dev docs.

I didn't realize it was a part of devDependencies but it looks to be a webpack file loader for timelion 🦁 . But even as a devDependency it's also a build dependency which could cause unknown issues. In some other case it could be that it is truly dev dependency (no unknown impact) and would be convenient to have on 8.x for some reason, I think that's perfectly fine.

Well, let's be a bit more pragmatic - how likely is it that a dev dependency upgrade with a green CI and a review from owners who know the dependency will break anything? 🙂

Take #216284 for example, we are upgrading vega to the latest patch version. I think this is ok for active branches still accepting features because these branches will have more thorough manual testing before being released. But we are backporting this to 8.17 and 8.18 which work fine as is and have no reason to upgrade this dependency. There's no security benefit or known kibana bug fix.

I wouldn't be as confident claiming that, considering that a member of the security team is upgrading the Vega dependency himself - even backporting it to 7.17 😛

--

Anyway, thanks a lot, folks, for the discussion - it's valuable. There are certainly things we can improve and clarify in our documentation and communication, but we should also acknowledge that our security, maintenance, and risk posture is evolving. Something that was considered OK in the past won't necessarily be OK in the future, and reviews of dependency upgrades might require just as much attention as any other feature or bug-fix review.

# Backport This will backport the following commits from `main` to `8.x`: - [Update dependency peggy to v4 (main) (#212280)](#212280) --------- Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>

elastic-renovate-prod bot added backport:all-open Backport to all branches that could still receive a release release_note:skip Skip the PR/issue when compiling release notes labels Feb 24, 2025

elastic-renovate-prod bot requested review from a team February 24, 2025 16:42

davismcphee added Team:Visualizations Team label for Lens, elastic-charts, Graph, legacy editors (TSVB, Visualize, Timelion) t// Team:DataDiscovery Discover, search (data plugin and KQL), data views, saved searches. For ES|QL, use Team:ES|QL. t// labels Feb 24, 2025

davismcphee self-assigned this Feb 24, 2025

Update dependency peggy to v4

89ab389

elastic-renovate-prod bot force-pushed the renovate/main-peggy branch from 4b66868 to 89ab389 Compare February 26, 2025 09:59

kertal requested a review from lukasolson March 3, 2025 16:51

kertal assigned lukasolson Mar 3, 2025

Merge branch 'main' into renovate/main-peggy

d592270

lukasolson added 2 commits March 10, 2025 18:20

Fix tests

9d8af2c

Merge branch 'main' into renovate/main-peggy

eebf239

lukasolson approved these changes Mar 11, 2025

View reviewed changes

Merge branch 'main' into renovate/main-peggy

b3b3828

lukasolson approved these changes Mar 11, 2025

View reviewed changes

mbondyra approved these changes Mar 11, 2025

View reviewed changes

lukasolson merged commit 238324a into main Mar 11, 2025
9 checks passed

This was referenced Mar 20, 2025

[8.17] Update dependency peggy to v4 (main) (#212280) #215391

Closed

[8.16] Update dependency peggy to v4 (main) (#212280) #215392

Closed

lukasolson mentioned this pull request Mar 20, 2025

[7.17] Update dependency peggy to v4 (main) (#212280) #215399

Closed

This was referenced Mar 21, 2025

Update dependency @openfeature/launchdarkly-client-provider to ^0.3.2 (main) #215232

Merged

Update dependency oniguruma-to-es to v4 (main) #215073

Merged

kibanamachine mentioned this pull request Mar 25, 2025

upgrade axios to 1.8.3 #214843

Merged

nickofthyme added backport:skip This PR does not require backporting and removed backport:all-open Backport to all branches that could still receive a release labels Mar 27, 2025

kibanamachine removed the backport missing Added to PRs automatically when the are determined to be missing a backport. label Mar 27, 2025

kibanamachine mentioned this pull request Mar 28, 2025

chore(deps): upgrade vega from 5.31.0 to 5.33.0 #216284

Merged

lukasolson added v8.19.0 v9.0.1 labels Mar 29, 2025

Conversation

elastic-renovate-prod bot commented Feb 24, 2025 • edited by kibanamachine Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Release Notes

New features

Bug fixes

Documentation

New features

Bug fixes

New features

Bug fixes

Documentation

Bug fixes

Bug fixes

Major Changes

Minor Changes

Bug Fixes

Minor Changes

Bug Fixes

Minor Changes

Bug Fixes

Major Changes

Minor Changes

Bug Fixes

Major Changes

Minor Changes

Bug Fixes

Major Changes

Minor Changes

Bug fixes

Configuration

Uh oh!

davismcphee commented Feb 24, 2025

Uh oh!

davismcphee commented Feb 24, 2025

Uh oh!

elasticmachine commented Feb 24, 2025

Uh oh!

elasticmachine commented Feb 24, 2025

Uh oh!

davismcphee commented Feb 24, 2025

Uh oh!

kertal commented Mar 3, 2025

Uh oh!

elastic-renovate-prod bot commented Mar 3, 2025

Edited/Blocked Notification

Uh oh!

kertal commented Mar 11, 2025

Uh oh!

lukasolson left a comment

Choose a reason for hiding this comment

Uh oh!

davismcphee commented Mar 11, 2025

Uh oh!

davismcphee commented Mar 11, 2025

Uh oh!

elasticmachine commented Mar 11, 2025

💚 Build Succeeded

Metrics [docs]

Async chunks

Page load bundle

History

Uh oh!

Uh oh!

kibanamachine commented Mar 21, 2025

Uh oh!

kibanamachine commented Mar 24, 2025

Uh oh!

kibanamachine commented Mar 25, 2025

Uh oh!

kibanamachine commented Mar 26, 2025

Uh oh!

nickofthyme commented Mar 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

azasypkin commented Mar 28, 2025

Uh oh!

nickofthyme commented Mar 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elastic-renovate-prod bot commented Feb 24, 2025 •

edited by kibanamachine

Loading

nickofthyme commented Mar 27, 2025 •

edited

Loading

nickofthyme commented Mar 28, 2025 •

edited

Loading

azasypkin commented Mar 28, 2025 •

edited

Loading

azasypkin commented Mar 28, 2025 •

edited

Loading

nickofthyme commented Mar 28, 2025 •

edited

Loading