feat: store dependencies graph in component model

[zkochan]

Proposed Changes

Example of the dependencies graph object:

https://gist.github.com/zkochan/ff6c5ad4aea7d1aa1b27cfab746cea59

TODO:

• get the dependency graph from root components.
• what to do if the component uses another component in the workspace? We don't know what the integrity of that component will be when it gets published.
• validate that component dependency versions are updated in the model in all scenarios
• make the change opt-in via the bit features env variable.
• importing components to an existing workspace (with an existing lockfile).
• don't write node_modules in e2e tests. We only need the lockfile. no way to skip install as next steps fail
• in e2e tests skip preview in tagged components previews are disabled in e2e tests by default
• Test what happens if you import 2 components - one with new data one without
• Test with old bit version when import/build a component with new data
• change feature flag to only use data
• Add an example of the data format into this PR
• ignore data if it has unsupported schema version.

Copilot reviewed 19 out of 34 changed files in this pull request and generated no suggestions.

Files not reviewed (15)

• package.json: Language not supported
• scopes/component/stash/stash-data.ts: Evaluated as low risk
• scopes/harmony/aspect-loader/aspect-loader.main.runtime.ts: Evaluated as low risk
• scopes/component/stash/stash.main.runtime.ts: Evaluated as low risk
• scopes/dependencies/pnpm/pnpm.package-manager.ts: Evaluated as low risk
• scopes/component/isolator/isolator.main.runtime.ts: Evaluated as low risk
• scopes/component/merging/merging.main.runtime.ts: Evaluated as low risk
• scopes/dependencies/pnpm/lockfile-converter.ts: Evaluated as low risk
• scopes/component/snapping/tag-model-component.ts: Evaluated as low risk
• scopes/dependencies/dependency-resolver/index.ts: Evaluated as low risk
• scopes/dependencies/dependency-resolver/dependency-resolver.main.runtime.ts: Evaluated as low risk
• scopes/component/apply/apply.main.runtime.ts: Evaluated as low risk
• scopes/dependencies/dependencies/dependencies.main.runtime.ts: Evaluated as low risk
• scopes/component/forking/forking.main.runtime.ts: Evaluated as low risk
• scopes/dependencies/dependency-resolver/dependency-installer.ts: Evaluated as low risk

Comments skipped due to low confidence (1)

scopes/dependencies/dependency-resolver/package-manager.ts:220

• [nitpick] The variable name componentIdByPkgName is ambiguous. It should be renamed to componentIdByPackageName.

componentIdByPkgName: ComponentIdByPkgName;

[GiladShoham]

Question: if I imported a few components (a,b), then I imported a few others (c,d), I will get here with the new ones (c,d) which means I'll build a graph based on c,d ids. which won't include a,b deps. isn't it will result in a wrong merged lock file?

[zkochan]

It will override the lockfile with dependencies of c and d. Dependencies of a and b will be resolved from scratch.

[GiladShoham]

I believe that in most cases we will be able to support older data, maybe it's for future, but maybe add a todo here to have a better mechanism , like minimal supported schema version

[zkochan]

But we don't know what the future version of the data will look like. I understand that maybe when the new version will come out, the new bit CLI will be able to process the previous version too. But the old version of bit CLI can't process the future format.