search

dgp1130 / rules_prerender

A Bazel rule set for prerending HTML pages.
13 stars 0 forks source link

Minify HTML #18

Open dgp1130 opened 3 years ago

dgp1130 commented 3 years ago

Before we could move this out of experimental and declare it ready for production, I think it is necessary to have some means of minifying the output HTML content. prerender_page_bundled() should automatically minify its outputs. prerender_page() probably doesn't need to support this since users of it are responsible for bundling/optimizing it themselves.

dgp1130 commented 3 years ago

There is a decision to be made about what enables production optimizations. There are a couple options:

  1. We could piggyback off -c (--compilation_mode), as -c opt is generally used to enable optimizations. However this appears targeted to C/C++ code, which isn't really applicable here. It can also be tricky for users to test, as they would likely need some kind of transition to optimize specific targets. Arguably users shouldn't have to test optimizations, but practically speaking, optimizations can and do break things, so there can definitely be a desire from users to do this.
  2. We could make our own flag --define prerender_mode=opt. This would allow us to make our own semantics rather than borrow existing ones. Ultimately this runs into the same problems as 1), except users can conditionally enable rules_prerender optimizations separate from other optimizations. However it is less intuitive, as users need to be told to set this flag for production releases, which many may not do. Setting -c opt is a much more reasonable expectation for release builds.
  3. We could expose optimization options as attributes on the relevant rule. In this case, minify_html = True could be an option on prerender_page_bundled(). This is probably the simplest, but it requires users to define two such rules, one for production and one for development, which could be quite annoying and take a non-trivial amount of effort. It also would not flow down the dependency graph like configurations naturally do, so optimizing a component would require adding the relevant option to all prerender_component() rule, rather than setting it on a single place.

I'm leaning a bit towards 1), as I think that is the way most projects handle this and its the most intuitive for users. I'll need to do some digging in rules_nodejs to see if they having any comparable precedent I can reference.