Follow-up fixes for ts-package-json-approved-dependencies rule#39129
Merged
Conversation
The entry for eng/approved-third-party-dependencies.yml was placed above the general /eng/ rule. Since CODEOWNERS resolves by last-matching pattern, the broad /eng/ rule was overriding it. Move the entry into the eng block so @Azure/azure-sdk-js-dev actually owns the allow-list file. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
APPROVED_DEPENDENCIES_RELATIVE_PATH and APPROVED_DEPENDENCIES_DISPLAY_PATH previously duplicated the path segments, so a rename could update one and miss the other. Derive both from a shared APPROVED_DEPENDENCIES_PATH_SEGMENTS array to prevent drift. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
maorleger
approved these changes
Jun 29, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
This PR is a small follow-up to #39105, which introduced the ts-package-json-approved-dependencies ESLint rule and its central allow-list (eng/approved-third-party-dependencies.yml). It addresses two post-merge review items: fixing CODEOWNERS so the allow-list file is actually owned by the right team, and removing path duplication in the rule's supporting utility.
Changes:
- Moved the
eng/approved-third-party-dependencies.ymlCODEOWNERS entry from near the top of the file into the eng block (after/eng/), so it becomes the last-matching pattern and@Azure/azure-sdk-js-devactually owns the file. - Introduced a private
APPROVED_DEPENDENCIES_PATH_SEGMENTSarray as a single source of truth, deriving bothAPPROVED_DEPENDENCIES_RELATIVE_PATHandAPPROVED_DEPENDENCIES_DISPLAY_PATHfrom it (values unchanged).
Show a summary per file
| File | Description |
|---|---|
.github/CODEOWNERS |
Relocates the allow-list ownership entry below the broad /eng/ rule so last-match resolution applies correctly. |
common/tools/eslint-plugin-azure-sdk/src/utils/approvedDependencies.ts |
Derives the relative and display allow-list paths from a shared segments array to prevent drift; exported constant names and values are unchanged. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Medium
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.
Addresses post-merge review feedback on #39105.
Changes
1. Fix CODEOWNERS ordering for the allow-list (maorleger, jeremymeng)
The
eng/approved-third-party-dependencies.ymlentry was placed near the top of.github/CODEOWNERS, above the general/eng/ @mikeharder @benbprule. Because CODEOWNERS resolves by last-matching pattern, the broad/eng/rule overrode the specific entry, so@Azure/azure-sdk-js-devdid not actually own the allow-list file. Moved the entry into the eng block (after/eng/) so it is the last match and takes effect.2. Derive allow-list paths from a single source of truth (maorleger)
APPROVED_DEPENDENCIES_RELATIVE_PATHandAPPROVED_DEPENDENCIES_DISPLAY_PATHindependently spelled out the path segments, so renaming the file could update one and miss the other. Both now derive from a sharedAPPROVED_DEPENDENCIES_PATH_SEGMENTSarray. Resulting values are byte-for-byte identical to before (relative path uses platform separators; display path forces/).Feedback intentionally not actioned
@scope/vs@scope/*, and theeventsdependency were all resolved by discussion on the original PR.@filefirst-party-scopes comment nit and the "throw on undefined root" suggestion were considered and left as-is.Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com