You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since rules_prerender heavily relies on explicitly defining JavaScript running in specific environments (client, server, build, ...), we should look into enforcing those constraints in the depgraph. It would be awesome if it was possible to define certain targets as "client-only" and adding a dependency in any other location would be an error. Something like:
# BUILD
ts_project(
name = "dom",
srcs = ["dom.ts"],
# Requires DOM, must be run in the browser.
restricted_to = ["@rules_prerender//platforms:browser"],
)
prerender_component(
name = "component",
prerender = ":dom", # ERROR: Must support `@rules_prerender//platforms:build`.
)
Unfortunately there are places where this gets cheated, such any environment with DOM emulation. It technically runs in Node, but actually has a DOM, which might be sufficient for some (but not all) browser code.
An important question here is how useful it actually is to enforce these constraints at the depgraph level. How common of a mistake is it to use a library in the wrong environment and how much does managing this get in the way. Ideally it would be great to find a path which optionally allowed these constraints but didn't force them for users who don't want to deal with it.
I don't know much about how restricted_to and compatible_with actually work and I'm struggled to find good docs right now. But something to consider as a way of making it potentially easier and more reliable to write portable JavaScript.
The text was updated successfully, but these errors were encountered:
Since
rules_prerender
heavily relies on explicitly defining JavaScript running in specific environments (client, server, build, ...), we should look into enforcing those constraints in the depgraph. It would be awesome if it was possible to define certain targets as "client-only" and adding a dependency in any other location would be an error. Something like:Unfortunately there are places where this gets cheated, such any environment with DOM emulation. It technically runs in Node, but actually has a DOM, which might be sufficient for some (but not all) browser code.
An important question here is how useful it actually is to enforce these constraints at the depgraph level. How common of a mistake is it to use a library in the wrong environment and how much does managing this get in the way. Ideally it would be great to find a path which optionally allowed these constraints but didn't force them for users who don't want to deal with it.
I don't know much about how
restricted_to
andcompatible_with
actually work and I'm struggled to find good docs right now. But something to consider as a way of making it potentially easier and more reliable to write portable JavaScript.The text was updated successfully, but these errors were encountered: