build(deps): bump the vue group across 1 directory with 2 updates - #2203
Conversation
dependabot
Bot
added
dependencies
|
|
/request-license-review |
✔️ All licenses already successfully vetted. Workflow run (with attached summary files): |
|
|
|
/request-license-review |
✔️ All licenses already successfully vetted. Workflow run (with attached summary files): |
|
dependabot
Bot
changed the title
69808e4 to
596282f
Compare
|
|
|
@dependabot rebase |
596282f to
4ca8c65
Compare
|
|
|
/request-license-review |
✔️ All licenses already successfully vetted. Workflow run (with attached summary files): |
|
/request-license-review |
✔️ All licenses already successfully vetted. Workflow run (with attached summary files): |
|
@dependabot recreate |
4ca8c65 to
42590b9
Compare
|
|
@akurtakov this issue is btw. one of the reason why I was voting for checking in the package.json lock file. This unvetted dependency is now breaking all unrelated PRs. It is a transitive dependency of the language server itself and probably got updated under the hood without us updating the language server dependencies. this dependency is no included in each binary build - no matter if we merge new PRs. this would not have happened with a versioned package.json lock file. |
Bumps the vue group with 2 updates in the /org.eclipse.wildwebdeveloper directory: [@vue/language-server](https://github.com/vuejs/language-tools/tree/HEAD/packages/language-server) and [@vue/typescript-plugin](https://github.com/vuejs/language-tools/tree/HEAD/packages/typescript-plugin). Updates `@vue/language-server` from 3.3.10 to 3.3.11 - [Release notes](https://github.com/vuejs/language-tools/releases) - [Changelog](https://github.com/vuejs/language-tools/blob/master/CHANGELOG.md) - [Commits](https://github.com/vuejs/language-tools/commits/v3.3.11/packages/language-server) Updates `@vue/typescript-plugin` from 3.3.10 to 3.3.11 - [Release notes](https://github.com/vuejs/language-tools/releases) - [Changelog](https://github.com/vuejs/language-tools/blob/master/CHANGELOG.md) - [Commits](https://github.com/vuejs/language-tools/commits/v3.3.11/packages/typescript-plugin) --- updated-dependencies: - dependency-name: "@vue/language-server" dependency-version: 3.3.11 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: vue - dependency-name: "@vue/typescript-plugin" dependency-version: 3.3.11 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: vue ... Signed-off-by: dependabot[bot] <support@github.com>
42590b9 to
7639b85
Compare
|
|
Wouldn't package lock also contain the vscode-uri update and thus prevent updates? |
|
For the reference https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/work_items/30482 is now fixed. |
no because it does not change transitive dependencies on unrelated PRs. |
|
How/when will transitive dependencies be updated in this case? Wouldn't we end up using combinations that majority of people will no longer get as npm will not produce it for them? |
|
transitive dependencies should be updated in a controlled way not potentially change on each build randomly. the NPM ecosystem is very volatile and other than in Maven transitive dependencies actually change without direct dependencies not being touched. if have a PR that updates a markdown dependency it is from my view inacceptable that the build can fail because deep down in the dependency hierarchy of another unrelated dependency a transitive dependency was updated on npmjs. thats why lockfiles lock the complete dependency tree. and thats why they are commited to git everywhere else except in this project. |
|
What is the proposal for a "controlled way of updating transitive dependencies" in automated way? |
|
Don't get me wrong - I would welcome your proposal as long as it doesn't lead to shipping older than what most people get combinations and/or more manual work. |
|
my proposal is to check in the lock file and update everything including transitive dependencies through dependabot PRs. nothing changes really compared to now except only the PRs will fail that try to bump an unvetted dependency. |
|
Would you please setup in your fork and show dependabot actually updating transitive deps in lockfiles? Just so we are sure it actually works. I assume we should see PRs for each transitive dependency? As that would probably increase the number of PRs significantly it would probably need auto merge setup for dependabot PRs for which all validations succeed. |
|
Honestly, this still feels again a bit like a ridiculous discussion. npm lockfiles are git committed and versioned. I don't think we need a proof of concept that it works and if so how. Usually you don't want transitive dependencies to update randomly, the only good reason is security and that is already covered by dependabot https://github.blog/changelog/2022-09-07-dependabot-unlocks-transitive-dependencies-for-npm-projects/ but again, this needs the lockfiles to be git committed. Even the official package.json documentation documents it: https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json I feel the only reason the file was not commited from the beginning in this repo is lack of knowledge of the NPM eco system. |
|
I have never claimed good knowledge of NPM ! But you would better fill your knowledge on the history of the project before doing more claims :) . Lock files have been committed initially and they have been removed as that allowed us to have less manual work to keep all the dependencies uptodate e.g. #222 . |
|
That decision may have been somewhat justified seven years ago but it even then introduced the real risk of publishing releases with unvetted transitive dependencies which kinda turns the whole Eclipse IP/license check ceremony ad absurdum. Also seven years ago there was no dependabot and github workflows for this repo. In the Maven eco system it is very unlikely if you specify a dependency in pom.xml that a transitive dependency will change. this is not the case in npm where often Version ranges are specified and where semantic versioning is often not followed despite versions looking like semantic versions. I'll see what I can do. |
^^ Exactly these "looks to be correct" but no one verifies them version ranges is why I insist on automatic uncovering and opening PRs instead of sticking to smth to uncover at runtime it no longer works.
Thanks, much appreciated! |
3 participants
Bumps the vue group with 2 updates in the /org.eclipse.wildwebdeveloper directory: @vue/language-server and @vue/typescript-plugin.
Updates
@vue/language-serverfrom 3.3.10 to 3.3.11Release notes
Sourced from @vue/language-server's releases.
... (truncated)
Changelog
Sourced from @vue/language-server's changelog.
Commits
f521b39v3.3.11 (#6174)Updates
@vue/typescript-pluginfrom 3.3.10 to 3.3.11Release notes
Sourced from @vue/typescript-plugin's releases.
... (truncated)
Changelog
Sourced from @vue/typescript-plugin's changelog.
Commits
f521b39v3.3.11 (#6174)