Open bennypowers opened 3 years ago
Yeah, monorepos are currently not very well supported yet, but I think it'll take more work than just the resolveModuleOrPackageSpecifier
function. That function really just only checks where an identifier comes from.
I think there will also be some changes needed in the inheritance plugin, which currently isnt very pluggable yet.
What would already also be helpful in a monorepo setup is the ability to define a path to the configuration file.
I think the CLI does not allow this. Manifest analyzer settings could be stored in a central file and (re-)used across packages.
What would already also be helpful in a monorepo setup is the ability to define a path to the configuration file.
This was implemented in v0.5.0
Goal: Plug in to analyzer's module resolution so I can resolve across monorepo packages
Relevant Code: https://github.com/open-wc/custom-elements-manifest/blob/d8bb5a6f33563abffb61f4a3d749656cb8804feb/packages/analyzer/src/utils/index.js#L18-L34
Given input like:
Analyser will identify
'@apollo-elements/core/apollo-query-controller';
as a bare specifier and quit. The final manifest for@apollo-elements/fast
will contain the members ofApolloQueryBehavior
, but not the members of its ancestorApolloQueryController
.I'd like to write a small plugin to hook into the module resolution so that I can point local monorepo imports to their relevant source files.
Alternatives
I think I could write a large plugin to collate manifest members across packages in
packageLinkPhase
, but it would be nicer to just use the core's code to do that stuff rather than replicate what analyzer does anyways.