Updating "ComponentFilePaths" list of Yarn's Workspace Dependencies.

[siyadava-sindhu]

Issue

• currenlty for "Yarn ecosystem" for identified workspace dependencies ., "locationsFoundAt" is coming only as parent 'Yarn.lock' (semantic version resolver of yarn-ecosystem), eventhough actual dependency usage in codebase is at respective workspace's Package.json entry.

Issue information with 1JS repo usecase

• Consider "1gql-schema/package.json" file of 1JS repo at 'https://office.visualstudio.com/Office/_git/1JS?path=/midgard/packages/1gql-schema/package.json' which has one of devDependency as "@graphql-codegen/add(3.2.1-resolved version)"

• On successful run of CG in 1JS ecosystem, in locationFoundAt list of "@graphql-codegen/add" we can see only source-folder entry as "Yarn.lock" but not ""1gql-schema/package.json"" in which code reference of '@graphql-codegen/add' exists.

• since actual usage of '@graphql-codegen/add' is in "1gql-schema/package.json" file from above example, in this PR aiming to add '"1gql-schema/package.json"' also one of the locationsFoundAt entry.

• one of CG-REST api call of locationsFoundAT values of 1JS(midgard) repo for quick reference of above example is as follows:

• https://governance.dev.azure.com/office/Office/_apis/componentgovernance/GovernedRepositories/169528/componentlocationsfile?snapshotId=114646097&api-version=7.1-preview.1

• Above REST-API has following values list w.r.t mentioned example:

"""""
"@graphql-codegen/add 3.2.1 -Npm:[
{
"filePath":/s/midgard/.store/@graphql-codegen-add@3.2.1-9682c5a89873a23a208f/node_modules/@graphql-codegen/add/package.json
},
{
"filePath":/s/midgard/.store/@graphql-codegen-import-types-preset@2.2.3-1725db1442e85dd3e793/node_modules/@graphql-codegen/add/package.json
},
{
"filePath":"/s/midgard/yarn.lock"
}
],
""""""""""

Reason and fix
-->currenlty for 'Yarn Ecosystem' summarized logic of parsing is that:
(1) YarnLockComponentDetector gets triggered when any 'yarn.lock' file gets found
(2) Inside 'YarnLockComponentDetector' class, "GetWorkspaceDependencies" API gets called to identify all "package.json" file's dependencies ,in workspace folder to which #1 yarn.lock is acting as semver-resolver..
-->in above steps, during execution of #2 step, (which gets spawned because of #1),No extra logic to add respective package.json's filelocation exists, and since source-trigger file of #2's package.json file is also #1's yarn.lock file
only "Location to which corresponding component belongs to" is added as Yarn.lock.
-->In this PR added extra logic at step-#2 to add respective package.json filepath also to LocationsFoundAt list, since actual usage of dependency is found at corresponding package.json.

why we are updating LocationsPath to add package.json data too

• Currently we are using "LocationsPath" of component in DependencyManagement project as real source of truth w.r.t where
  component is identified, and further using ownership-extension (with filepath) to know owner of respective filepath.
• since in this usecase , as actual package.json filepath didn't got added to "LocationsPath" list, for all packages of yarn ecosystem repo(especially in monorepo scenarios where each package.json file is owned by different teams), owner is coming to be same person who owned common "Yarn.lock", instead of respective package.json.

Validations
-->By parsing 1Js repo validated locally that along with yarn.lock filepath, respective package.json path is also showing up in locationsFoundAt list for workspaceDependency entries,

[JamieMagee]

Can you add new tests to validate the behaviour?

[siyadava-sindhu]

Can you add new tests to validate the behaviour?

Added 'WellFormedYarnLockV1WithWorkspace_CheckFilePathsAsync' test in YarnLockDetectorTests to validate Workspace's filepath functionality.

[melotic]

@JamieMagee This looks good to me, but I'm not too knowledgeable in the yarn ecosystem to be 100% confident.

[github-actions]

👋 Hi! It looks like you modified some files in the Detectors folder.
You may need to bump the detector versions if any of the following scenarios apply:

• The detector detects more or fewer components than before
• The detector generates different parent/child graph relationships than before
• The detector generates different devDependencies values than before

If none of the above scenarios apply, feel free to ignore this comment 🙂