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

Extract published components #64

Open
dgp1130 opened this issue Feb 14, 2023 · 1 comment
Open

Extract published components #64

dgp1130 opened this issue Feb 14, 2023 · 1 comment
Labels
feature New feature or request
Milestone

Comments

@dgp1130
Copy link
Owner

dgp1130 commented Feb 14, 2023

Currently link_prerender_component() has a pretty minimal implementation. It doesn't support CSS or resources and just copies the same NPM package for prerendering and client-side scripts. We should make a proper extractor which splits the NPM package into distinct TreeArtifacts containing all the individual files for each slice. A few challenges with making this happen:

  1. We basically don't know anything until execution time. What resource files exist, what CSS files exist, etc. is no longer known at analysis time. This means all our providers and implementation details around prerender_component() and prerender_pages() need to be updated to not require analysis-time knowledge. This is probably most impactful for CSS import resolution, which is currently done at analysis time and will need to be updated.
  2. Prerender and client side JS need to be separated, but both should be importable from the same NPM package. This means we'd need to link two different implementations for the same NPM package. This could introduce weird errors if they were ever both imported in the same target (which generally shouldn't happen but is technically possible).
  3. Prerender and client side JS need to exist in two distinct TreeArtifacts but are imported by the package of that name. If we generate dist/bin/node_modules/@rules_prerender/declarative_shadow_dom_prerender, then it would be laid out that way in the output dir of the renderer binary, meaning it needs to be imported at @rules_prerender/declarative_shadow_dom_prerender. We could trivially name the directory the same as the target, but only one directory can have that name, and we have two, leading to conflicts.
@dgp1130 dgp1130 added the feature New feature or request label Feb 14, 2023
@dgp1130 dgp1130 added this to the 1.0.0 milestone Mar 17, 2023
@dgp1130
Copy link
Owner Author

dgp1130 commented Mar 17, 2023

Not sure if this is strictly necessary for 1.0.0 if what I have is good enough for officially supported prerender_components(), but I'm adding it to the milestone to make sure I at least don't forget as we approach 1.0.0.

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

No branches or pull requests

1 participant