prerender_resources()
#28
Labels
feature
New feature or request
Comments
dgp1130
added a commit
that referenced
this issue
Jun 27, 2021
Refs #28. This introduces a new `prerender_resources()` macro, which is a lower-level of abstraction than `prerender_pages_unbundled()`. It is responsible for simply generating an executing the renderer and collecting its output in a directory. It does **not** perform any subsequent processing like extracting annotations or generating scripts or styles. As a result, this has no hard or implicit expectation that user code generates HTML files, making this a good candidate for scripts which generate raw data instead of actual web pages. One consequence of this is that it does *not* make sense to depend on `prerender_component()` targets, because the output is not a web page and will not be bundled. This means that `prerender_resources()` simply takes a `ts_library()` (or any JavaScript files) as inputs, giving the macro less responsibility. The downside however is that we need to replicate the `entry_point` behavior of `nodejs_binary()`, which is quite involved and I don't want to match that exactly. Instead, `prerender_resources()` requires the full workspace-relative path to be provided. This avoids ambiguity, but is a little annoying and easy to screw up. I did try to require the workspace itself in the path, but this would break `prerender_pages_unbundled()` because there is no way to look up the workspace name in a macro. For now, `prerender_resources()` just doesn't support source files in a different workspace, requiring users to manually copy them over.
|
Added a new macro |
dgp1130
added a commit
that referenced
this issue
Aug 15, 2021
Closes #28. This example uses `prerender_resources()` to generate a couple text files and a binary file, then confirms that they were generated as expected. This shows how users can easily generate non-HTML files in their builds.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For users who generate binary or non-HTML content,
prerender_multi_page()is a bit heavyweight. For starters, it has "page" in the name, implying its intended usage for HTML pages. It also extracts annotations, builds entry points, and exports scripts and styles. If you are just generating images, none of this infrastructure is useful. fortunately Bazel is smart enough to not execute those tools if users don't depend on them, however it is still excess infrastructure, clutters the dependency graph, and generally obfuscates the actual build.As an alternative for such use cases, I'm thinking of
prerender_raw_resources(), which is effectively a direct invocation of the renderer tool. It will invoke user code to generate a directory and stop there. No annotations are extracted, no entry points generated, no scripts or styles exported. This would enable users to leverage the renderer independently of otherrules_prerenderinfrastructure. It would also be most useful for cases whereextract_single_resources()is used, since it would likely be extracting from an unbundled directory where none of the other outputs ofprerender_multi_page()are useful.The text was updated successfully, but these errors were encountered: