Bundle legend-graph separately from vscode-extension-dependencies

[travisstebbins]

Summary

This PR bundles @finos/legend-graph separately from the rest of @finos/legend-vscode-extension-dependencies so that when other VS Code extension packages have multiple dependencies that depend on @finos/legend-graph, we can use webpack to alias all of them to the same instance of @finos/legend-graph. This is necessary because without this, different dependencies will have their own copies of @finos/legend-graph which will cause instanceof checks to fail, since they will technically be using different copies of the classes in @finos/legend-graph.

How did you test this change?

• Test(s) added
• Manual testing (please provide screenshots/recordings)
• No testing (please provide an explanation)

No testing as just adding rollup config to @finos/legend-graph.

[changeset-bot]

🦋 Changeset detected

Latest commit: c02fe8e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 31 packages

Name	Type
@finos/legend-vscode-extension-dependencies	Patch
@finos/legend-graph	Patch
@finos/legend-application-data-cube	Patch
@finos/legend-application-pure-ide	Patch
@finos/legend-application-query-bootstrap	Patch
@finos/legend-application-query	Patch
@finos/legend-application-repl	Patch
@finos/legend-application-studio-bootstrap	Patch
@finos/legend-application-studio	Patch
@finos/legend-code-editor	Patch
@finos/legend-data-cube	Patch
@finos/legend-extension-assortment	Patch
@finos/legend-extension-dsl-data-quality	Patch
@finos/legend-extension-dsl-data-space-studio	Patch
@finos/legend-extension-dsl-data-space	Patch
@finos/legend-extension-dsl-diagram	Patch
@finos/legend-extension-dsl-persistence	Patch
@finos/legend-extension-dsl-service	Patch
@finos/legend-extension-dsl-text	Patch
@finos/legend-extension-store-flat-data	Patch
@finos/legend-extension-store-relational	Patch
@finos/legend-extension-store-service-store	Patch
@finos/legend-lego	Patch
@finos/legend-query-builder	Patch
@finos/legend-application-data-cube-bootstrap	Patch
@finos/legend-application-pure-ide-deployment	Patch
@finos/legend-application-query-deployment	Patch
@finos/legend-application-repl-deployment	Patch
@finos/legend-application-studio-deployment	Patch
@finos/legend-application-data-cube-deployment	Patch
@finos/legend-server-showcase-deployment	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 45.71%. Comparing base (47f6d3f) to head (c02fe8e).
Report is 5 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3859      +/-   ##
==========================================
- Coverage   45.75%   45.71%   -0.05%     
==========================================
  Files        2249     2249              
  Lines      392585   392409     -176     
  Branches    16334    17037     +703     
==========================================
- Hits       179640   179392     -248     
- Misses     212202   212312     +110     
+ Partials      743      705      -38     

Files with missing lines	Coverage Δ
.../legend-vscode-extension-dependencies/src/index.ts	0.00% <ø> (ø)

... and 410 files with indirect coverage changes

[akphi]

@travisstebbins I understand the rationale of this change, but this is not solving the root problem, we have instanceof checks for things coming from @finos/legend-shared as well, so maybe a while from now, we would need to CJS bundle that module, etc. At the end of the day, the right solution is probably to build CJS for each and every module.

Now, in the particular setup we have, if you need to include some proprietary extensions, then the easiest will be to replicate exactly what we do here in vscode-extension-dependencies module, let's say, create a module called proprietary-vscode-extension-dependencies that bundles everything like in vscode-extension-dependencies plus the proprietary extensions.

[travisstebbins]

@travisstebbins I understand the rationale of this change, but this is not solving the root problem, we have instanceof checks for things coming from @finos/legend-shared as well, so maybe a while from now, we would need to CJS bundle that module, etc. At the end of the day, the right solution is probably to build CJS for each and every module.

Now, in the particular setup we have, if you need to include some proprietary extensions, then the easiest will be to replicate exactly what we do here in vscode-extension-dependencies module, let's say, create a module called proprietary-vscode-extension-dependencies that bundles everything like in vscode-extension-dependencies plus the proprietary extensions.

Thanks for the tip! I do think in the longer term it would make sense to have CJS versions of all our packages available. However, in the meantime, I was able to get my proprietary extensions to work by creating a proprietary-vscode-extension-dependencies package, which has a src/index.ts file that contains export * from '@finos/legend-vscode-extension-dependencies' + exporting all the proprietary code, and then bundling that src/index.ts file with rollup.