chore: update package versions to resolve Dependabot alerts - #330
Closed
NirajC3-Microsoft wants to merge 10 commits into
Closed
chore: update package versions to resolve Dependabot alerts#330NirajC3-Microsoft wants to merge 10 commits into
NirajC3-Microsoft wants to merge 10 commits into
Conversation
Contributor
Author
|
@microsoft-github-policy-service agree company="Microsoft" |
Coverage Report •
|
Processor Coverage Report •
|
NirajC3-Microsoft
marked this pull request as ready for review
July 24, 2026 02:50
NirajC3-Microsoft
requested review from
Avijit-Microsoft,
Prajwal-Microsoft,
Roopan-Microsoft,
Vinay-Microsoft,
aniaroramsft,
dgp10801,
nchandhi,
sethsteenken and
toherman-msft
as code owners
July 24, 2026 02:50
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 8 changed files in this pull request and generated no new comments.
Files not reviewed (1)
- src/frontend/package-lock.json: Generated file
Comments suppressed due to low confidence (12)
src/frontend/package-lock.json:151
- This lockfile entry is pinned to an Azure Artifacts "ms-feed-*.pkgs.visualstudio.com" tarball URL (and uses a sha1 integrity). If contributors/CI don’t have access to that feed, installs will fail and the build won’t be reproducible from the public npm registry. Consider regenerating package-lock.json with the intended public registry (or add a repo .npmrc documenting/configuring the required registry) so the lockfile doesn’t depend on an implicit private feed.
src/frontend/package-lock.json:182 - This lockfile entry is pinned to an Azure Artifacts "ms-feed-*.pkgs.visualstudio.com" tarball URL (and uses a sha1 integrity). If contributors/CI don’t have access to that feed, installs will fail and the build won’t be reproducible from the public npm registry. Consider regenerating package-lock.json with the intended public registry (or add a repo .npmrc documenting/configuring the required registry) so the lockfile doesn’t depend on an implicit private feed.
src/frontend/package-lock.json:258 - This lockfile entry is pinned to an Azure Artifacts "ms-feed-*.pkgs.visualstudio.com" tarball URL (and uses a sha1 integrity). If contributors/CI don’t have access to that feed, installs will fail and the build won’t be reproducible from the public npm registry. Consider regenerating package-lock.json with the intended public registry (or add a repo .npmrc documenting/configuring the required registry) so the lockfile doesn’t depend on an implicit private feed.
src/frontend/package-lock.json:268 - This lockfile entry is pinned to an Azure Artifacts "ms-feed-*.pkgs.visualstudio.com" tarball URL (and uses a sha1 integrity). If contributors/CI don’t have access to that feed, installs will fail and the build won’t be reproducible from the public npm registry. Consider regenerating package-lock.json with the intended public registry (or add a repo .npmrc documenting/configuring the required registry) so the lockfile doesn’t depend on an implicit private feed.
src/frontend/package-lock.json:302 - This lockfile entry is pinned to an Azure Artifacts "ms-feed-*.pkgs.visualstudio.com" tarball URL (and uses a sha1 integrity). If contributors/CI don’t have access to that feed, installs will fail and the build won’t be reproducible from the public npm registry. Consider regenerating package-lock.json with the intended public registry (or add a repo .npmrc documenting/configuring the required registry) so the lockfile doesn’t depend on an implicit private feed.
src/frontend/package-lock.json:364 - This lockfile entry is pinned to an Azure Artifacts "ms-feed-*.pkgs.visualstudio.com" tarball URL (and uses a sha1 integrity). If contributors/CI don’t have access to that feed, installs will fail and the build won’t be reproducible from the public npm registry. Consider regenerating package-lock.json with the intended public registry (or add a repo .npmrc documenting/configuring the required registry) so the lockfile doesn’t depend on an implicit private feed.
src/frontend/package-lock.json:4571 - This lockfile entry is pinned to an Azure Artifacts "ms-feed-*.pkgs.visualstudio.com" tarball URL (and uses a sha1 integrity). If contributors/CI don’t have access to that feed, installs will fail and the build won’t be reproducible from the public npm registry. Consider regenerating package-lock.json with the intended public registry (or add a repo .npmrc documenting/configuring the required registry) so the lockfile doesn’t depend on an implicit private feed.
src/frontend/package-lock.json:4615 - This lockfile entry is pinned to an Azure Artifacts "ms-feed-*.pkgs.visualstudio.com" tarball URL (and uses a sha1 integrity). If contributors/CI don’t have access to that feed, installs will fail and the build won’t be reproducible from the public npm registry. Consider regenerating package-lock.json with the intended public registry (or add a repo .npmrc documenting/configuring the required registry) so the lockfile doesn’t depend on an implicit private feed.
src/frontend/package-lock.json:5662 - This lockfile entry is pinned to an Azure Artifacts "ms-feed-*.pkgs.visualstudio.com" tarball URL (and uses a sha1 integrity). If contributors/CI don’t have access to that feed, installs will fail and the build won’t be reproducible from the public npm registry. Consider regenerating package-lock.json with the intended public registry (or add a repo .npmrc documenting/configuring the required registry) so the lockfile doesn’t depend on an implicit private feed.
src/frontend/package-lock.json:7545 - This lockfile entry is pinned to an Azure Artifacts "ms-feed-*.pkgs.visualstudio.com" tarball URL (and uses a sha1 integrity). If contributors/CI don’t have access to that feed, installs will fail and the build won’t be reproducible from the public npm registry. Consider regenerating package-lock.json with the intended public registry (or add a repo .npmrc documenting/configuring the required registry) so the lockfile doesn’t depend on an implicit private feed.
infra/vscode_web/requirements.txt:3 - This changes the constraint from a compatible-release pin (previously limited to a minor series) to an unbounded lower bound, which can allow future minor/major ansible-core releases to be pulled in automatically and potentially break provisioning unexpectedly. Consider keeping a compatible-release style constraint while addressing the security advisory (e.g.,
~=2.18.18).
ansible-core>=2.18.18
infra/vscode_web/endpoint-requirements.txt:3
- This changes the constraint from a compatible-release pin (previously limited to a minor series) to an unbounded lower bound, which can allow future minor/major ansible-core releases to be pulled in automatically and potentially break provisioning unexpectedly. Consider keeping a compatible-release style constraint while addressing the security advisory (e.g.,
~=2.18.18).
ansible-core>=2.18.18
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 8 changed files in this pull request and generated no new comments.
Files not reviewed (1)
- src/frontend/package-lock.json: Generated file
Comments suppressed due to low confidence (7)
infra/vscode_web/requirements.txt:3
ansible-coreis now specified with a minimum version only (>=2.18.18), while the rest of this requirements file uses pinned versions. Leaving it unbounded can introduce breaking changes on future installs and reduces reproducibility.
ansible-core>=2.18.18
infra/vscode_web/endpoint-requirements.txt:3
ansible-coreis now specified with a minimum version only (>=2.18.18), while the rest of this requirements file uses pinned versions. Leaving it unbounded can introduce breaking changes on future installs and reduces reproducibility.
ansible-core>=2.18.18
src/frontend/package-lock.json:151
- This lockfile entry is resolved from an internal Visual Studio/Azure Artifacts feed (
ms-feed-*.pkgs.visualstudio.com) and usessha1integrity, while most of the lockfile usesregistry.npmjs.org+sha512. Committing feed-specificresolvedURLs can breaknpm cifor contributors/CI that don't have that feed configured and reduces integrity strength.
src/frontend/package-lock.json:4571 - This entry is resolved from an internal Visual Studio/Azure Artifacts feed (
ms-feed-*.pkgs.visualstudio.com) and usessha1integrity. That’s inconsistent with the rest of the lockfile (mostlyregistry.npmjs.org+sha512) and can make installs fail in environments without that feed configured.
src/frontend/package-lock.json:4615 - This entry is resolved from an internal Visual Studio/Azure Artifacts feed (
ms-feed-*.pkgs.visualstudio.com) and usessha1integrity. If contributors/CI don’t have that feed configured,npm cican fail even though the version exists on the public npm registry.
src/frontend/package-lock.json:5663 - This entry is resolved from an internal Visual Studio/Azure Artifacts feed (
ms-feed-*.pkgs.visualstudio.com) and usessha1integrity, unlike most entries in this lockfile. This reduces reproducibility and can break installs outside of Microsoft-internal environments.
src/frontend/package-lock.json:7545 - This entry is resolved from an internal Visual Studio/Azure Artifacts feed (
ms-feed-*.pkgs.visualstudio.com) and usessha1integrity. Since the rest of the lockfile primarily usesregistry.npmjs.org+sha512, this looks like the lockfile was generated with a custom registry and may not be installable everywhere.
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 8 changed files in this pull request and generated no new comments.
Files not reviewed (1)
- src/frontend/package-lock.json: Generated file
Comments suppressed due to low confidence (5)
infra/vscode_web/requirements.txt:3
- Using an open-ended lower bound (">=") for ansible-core makes installs non-reproducible and can unintentionally pull in breaking changes. This file previously used the compatible-release operator (~=); consider keeping that pattern by pinning to the 2.18 patch line.
ansible-core>=2.18.18
infra/vscode_web/endpoint-requirements.txt:3
- Using an open-ended lower bound (">=") for ansible-core makes installs non-reproducible and can unintentionally pull in breaking changes. This file previously used the compatible-release operator (~=); consider keeping that pattern by pinning to the 2.18 patch line.
ansible-core>=2.18.18
src/frontend/package-lock.json:151
- These updated entries switch to an Azure Artifacts feed URL and use a sha1 integrity hash. This reduces portability (developers/CI without access to that feed can’t reproduce installs) and sha1 integrity is weaker than the typical sha512 recorded by npm.
src/frontend/package-lock.json:4571 - This axios lock entry uses an Azure Artifacts feed URL and a sha1 integrity hash, which can break reproducible installs outside that environment and weakens integrity verification compared to the usual sha512.
src/frontend/package-lock.json:7546 - This js-yaml lock entry uses an Azure Artifacts feed URL and a sha1 integrity hash, which can hinder reproducible installs and weakens integrity verification compared to sha512.
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 8 changed files in this pull request and generated no new comments.
Files not reviewed (1)
- src/frontend/package-lock.json: Generated file
Comments suppressed due to low confidence (4)
src/processor/pyproject.toml:30
mem0aiandqdrant-clientare specified with>=while all other runtime deps in this list are pinned with==. Mixing specifier styles makes the project dependencies less deterministic (a futureuv lockcould silently move these to newer versions), and it’s inconsistent with the rest of this file’s pinning strategy.
Consider pinning these to the versions currently resolved in the lockfile for reproducible builds.
"mcp==1.28.1",
"mem0ai>=2.0.1",
"openai==2.33.0",
"psutil==7.2.2",
"pytz==2026.1.post1",
src/frontend/package-lock.json:151
- This lockfile now contains
resolvedURLs pointing atms-feed-*.pkgs.visualstudio.comand usessha1-...integrity hashes for some packages (example:@babel/core). Since most of the lockfile still points atregistry.npmjs.orgwithsha512integrity, this introduces an inconsistent dependency source and weaker integrity verification, and may break installs in CI/dev environments that don’t have access to that feed.
Regenerate package-lock.json using the intended registry configuration (or commit an .npmrc that consistently configures the registry for all environments) so resolved/integrity are stable and portable.
infra/vscode_web/requirements.txt:3
- The constraint changed from a compatible-release pin (
~=) to a minimum-only (>=). Without an upper bound, this can pull in newer minor/majoransible-coreversions and increase the chance of unexpected breakages.
If the intent is “2.18.x starting from 2.18.18”, keep the previous compatible-release style (or add an explicit upper bound).
ansible-core>=2.18.18
infra/vscode_web/endpoint-requirements.txt:3
- The constraint changed from a compatible-release pin (
~=) to a minimum-only (>=). Without an upper bound, this can pull in newer minor/majoransible-coreversions and increase the chance of unexpected breakages.
If the intent is “2.18.x starting from 2.18.18”, keep the previous compatible-release style (or add an explicit upper bound).
ansible-core>=2.18.18
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 8 changed files in this pull request and generated no new comments.
Files not reviewed (1)
- src/frontend/package-lock.json: Generated file
Comments suppressed due to low confidence (10)
infra/vscode_web/requirements.txt:3
- These requirements files pin other dependencies exactly, but ansible-core is now specified as a bare lower bound (>=2.18.18). This removes the previous upper bound and can allow unexpected major/minor upgrades, reducing reproducibility and potentially breaking the VS Code web infra unexpectedly. Consider using a compatible-release specifier (~=2.18.18) (or an exact pin) to keep upgrades controlled while still addressing the Dependabot alert.
azure-ai-projects==2.1.0
azure-identity==1.20.0
ansible-core>=2.18.18
infra/vscode_web/endpoint-requirements.txt:3
- These requirements files pin other dependencies exactly, but ansible-core is now specified as a bare lower bound (>=2.18.18). This removes the previous upper bound and can allow unexpected major/minor upgrades, reducing reproducibility and potentially breaking the VS Code web infra unexpectedly. Consider using a compatible-release specifier (~=2.18.18) (or an exact pin) to keep upgrades controlled while still addressing the Dependabot alert.
azure-ai-projects==1.0.0b12
azure-identity==1.20.0
ansible-core>=2.18.18
src/processor/pyproject.toml:31
- mem0ai and qdrant-client are the only project dependencies here that use open-ended ">=" ranges while the rest of the dependency list is pinned with "==". This can lead to non-reproducible installs (different versions across environments) and makes it harder to correlate Dependabot/security alerts to a specific resolved version. Consider pinning these to the versions already resolved in uv.lock.
"mem0ai>=2.0.1",
"openai==2.33.0",
"psutil==7.2.2",
"pytz==2026.1.post1",
"qdrant-client>=1.17.1",
src/frontend/package-lock.json:151
- Several new/updated entries in package-lock.json now resolve to "https://ms-feed-*.pkgs.visualstudio.com/..." and use sha1 integrity hashes. This makes installs dependent on an Azure Artifacts feed (which may be inaccessible in CI or for external contributors) and weakens integrity verification compared to the sha512 hashes used elsewhere in this lockfile. Regenerate the lockfile with npm configured to use the public registry (e.g., https://registry.npmjs.org) so resolved URLs and integrity values are portable and use strong hashes.
src/frontend/package-lock.json:257 - Several new/updated entries in package-lock.json now resolve to "https://ms-feed-*.pkgs.visualstudio.com/..." and use sha1 integrity hashes. This makes installs dependent on an Azure Artifacts feed (which may be inaccessible in CI or for external contributors) and weakens integrity verification compared to the sha512 hashes used elsewhere in this lockfile. Regenerate the lockfile with npm configured to use the public registry (e.g., https://registry.npmjs.org) so resolved URLs and integrity values are portable and use strong hashes.
src/frontend/package-lock.json:301 - Several new/updated entries in package-lock.json now resolve to "https://ms-feed-*.pkgs.visualstudio.com/..." and use sha1 integrity hashes. This makes installs dependent on an Azure Artifacts feed (which may be inaccessible in CI or for external contributors) and weakens integrity verification compared to the sha512 hashes used elsewhere in this lockfile. Regenerate the lockfile with npm configured to use the public registry (e.g., https://registry.npmjs.org) so resolved URLs and integrity values are portable and use strong hashes.
src/frontend/package-lock.json:4570 - Several new/updated entries in package-lock.json now resolve to "https://ms-feed-*.pkgs.visualstudio.com/..." and use sha1 integrity hashes. This makes installs dependent on an Azure Artifacts feed (which may be inaccessible in CI or for external contributors) and weakens integrity verification compared to the sha512 hashes used elsewhere in this lockfile. Regenerate the lockfile with npm configured to use the public registry (e.g., https://registry.npmjs.org) so resolved URLs and integrity values are portable and use strong hashes.
src/frontend/package-lock.json:4614 - Several new/updated entries in package-lock.json now resolve to "https://ms-feed-*.pkgs.visualstudio.com/..." and use sha1 integrity hashes. This makes installs dependent on an Azure Artifacts feed (which may be inaccessible in CI or for external contributors) and weakens integrity verification compared to the sha512 hashes used elsewhere in this lockfile. Regenerate the lockfile with npm configured to use the public registry (e.g., https://registry.npmjs.org) so resolved URLs and integrity values are portable and use strong hashes.
src/frontend/package-lock.json:5662 - Several new/updated entries in package-lock.json now resolve to "https://ms-feed-*.pkgs.visualstudio.com/..." and use sha1 integrity hashes. This makes installs dependent on an Azure Artifacts feed (which may be inaccessible in CI or for external contributors) and weakens integrity verification compared to the sha512 hashes used elsewhere in this lockfile. Regenerate the lockfile with npm configured to use the public registry (e.g., https://registry.npmjs.org) so resolved URLs and integrity values are portable and use strong hashes.
src/frontend/package-lock.json:7545 - Several new/updated entries in package-lock.json now resolve to "https://ms-feed-*.pkgs.visualstudio.com/..." and use sha1 integrity hashes. This makes installs dependent on an Azure Artifacts feed (which may be inaccessible in CI or for external contributors) and weakens integrity verification compared to the sha512 hashes used elsewhere in this lockfile. Regenerate the lockfile with npm configured to use the public registry (e.g., https://registry.npmjs.org) so resolved URLs and integrity values are portable and use strong hashes.
Contributor
Author
|
Not required wrong PR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
This pull request updates a range of backend and frontend dependencies to improve compatibility, security, and stability across the project. The main changes include upgrading Python and Node.js package versions, tightening Python version requirements, and adding or updating several dependencies in both backend and frontend configuration files.
Backend dependency updates and requirements:
ansible-coreto>=2.18.18in bothinfra/vscode_web/endpoint-requirements.txtandinfra/vscode_web/requirements.txtfor better compatibility and support. [1] [2]>=3.12,<3.14insrc/backend-api/pyproject.tomlto avoid issues with future Python releases.src/backend-api/pyproject.toml, including:pydantic-settingsto2.14.2starletteto1.3.1pyjwtto2.13.0mcp==1.28.1mcpto1.28.1and addedjoserfc==1.6.8insrc/processor/pyproject.tomlfor improved JWT handling. [1] [2]Frontend dependency updates:
src/frontend/package.jsonandpackage-lock.json:axiosto^1.18.1[1] [2] [3]js-yamlto^4.3.0[1] [2] [3]dompurifyto3.4.12,brace-expansionto5.0.7, and@babel/coreto7.29.6[1] [2] [3] [4]7.29.6or7.29.7for improved build tooling and compatibility. [1] [2] [3] [4] [5]These updates ensure the project remains up-to-date with the latest features, security patches, and compatibility improvements across both backend and frontend components.
Does this introduce a breaking change?
Golden Path Validation
Deployment Validation
What to Check
Verify that the following are valid
Other Information