Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Analyser][Schema] Using Typescript as input results in TS file path in def.declaration.module rather than complied JS output #236

Closed
1 of 2 tasks
xenobytezero opened this issue Feb 28, 2024 · 2 comments

Comments

@xenobytezero
Copy link
Contributor

Checklist

  • Did you run the analyzer with the --dev flag to get more information?
  • Did you create a minimal reproduction in the playground? - NA - Requires Typescript

Expected behavior

When using TS files as the inputs to the analyzer, the output manifest for export items points at the source TS files rather than the compiled JS output.

While this is to be expected, as the plugin has no way of knowing where the compiled output would be, it means that the exports section of the manifest is essentially useless in a package where the source is not also distributed.

We are using the manifests internally as part of our system to determine which JS files to send to the client based on requested components, and this is the only parameter in the manifest that would provide this information.

We have built a plugin for the analyzer that uses the output d.ts.map to change this value on output so we are not neccessarily asking for changes to the core analyser, we more have questions.

  1. The definition of the schema describes the decleration section as

A reference to the class or other declaration that implements the custom element.

Does this imply that this should point at the compiled output rather than the source input?

  1. We are pointing at the input TS files since we strip all documentation out of the compiled version, and so lose features like CSS Part, etc. Is there some better way of doing this that would avoid this problem altogether?
@thepassle
Copy link
Member

We are pointing at the input TS files since we strip all documentation out of the compiled version, and so lose features like CSS Part, etc. Is there some better way of doing this that would avoid this problem altogether?

... a plugin for the analyzer that uses the output d.ts.map to change this value on output

This describes exactly the problem :) The manifest, according to the Schema, should be pointing at the distributed code. However, we can't make assumptions on what kind of build systems of config settings every project has, so it's not feasible for the analyzer itself to make those assumptions. Instead you should indeed use a plugin that changes the paths/file extensions, like the one you built, or something like https://www.npmjs.com/package/cem-plugin-module-file-extensions

Additionally, running the analyzer on the TS output would lose a bunch of information.

@xenobytezero
Copy link
Contributor Author

Thanks for the response, makes a lot of sense. Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants