0.0.13

https://www.npmjs.com/package/rules_prerender/v/0.0.13

Changelog:

#47 - Renames inline_styles to styles.

BREAKING CHANGES:

#47 - There is no longer any concept of global styles, all styles are inlined. This means:

• includeStyle() is removed.
• styles now refers to inlined styles, there is no way to depend on global styles.
• inline_styles attributes on all prerender_*() rules is removed.
• Various other minor breaking changes to remove global styles and rename "inline styles" to "styles".

0.0.12

https://www.npmjs.com/package/rules_prerender/v/0.0.12

BREAKING CHANGES:

• 831b592 - Removes inlineStyleLegacy(). Use inlineStyle() instead.
• e84df1d - Removes css_group(). Only use case is for prerender_resources() rendering an HTML page, use prerender_pages() or prerender_pages_unbundled() instead.

0.0.11

https://www.npmjs.com/package/rules_prerender/v/0.0.11

Main objective of this release is to bundle inlined CSS files to support @import and provide a CSS toolchain (#41). This implements a css_library() target to manage CSS dependencies and adds a new inline_styles attribute to prerender_*() rules which bundle their styles for inlining. @import should work as expected here.

See 0.0.11 README's example for more information about how inline_styles is expected to be used.

BREAKING CHANGES:

• inlineStyle() now only allows loading styles listed in inline_styles of the associated prerender_*() target. You can no longer inline files listed in styles.

0.0.10

https://www.npmjs.com/package/rules_prerender/v/0.0.10

Main objective of this release is to provide a convenient means of using Declarative Shadow DOM to author components with native style isolation.

Changelog:

BREAKING CHANGES:

• ab3747f - Bazel ^4.0.0 and rules_nodejs@^4.0.0 are required. NodeJS must still be on ^12.0.0 to for rules_postcss, see bazelbuild/rules_postcss#73.

Other changes:

• Refs #39 - prerender_component() now supports pure-JavaScript components, no TypeScript required. Simply pass in *.js (and optionally *.d.ts) files into a prerender_component() target's srcs (must be written in CommonJS for now). You can also use a js_library() in the scripts attribute for client-side JS (must be written in ESM format). A component's prerender code must be entirely JavaScript or entirely TypeScript (ignoring *.d.ts files, which can be used in either case). See //examples/javascript/... for a complete example.

# BUILD.bazel

load("@build_bazel_rules_nodejs//:index.bzl", "js_library")
load("@npm//rules_prerender:index.bzl", "prerender_component")

prerender_component(
    name = "my_component",
    srcs = [
        "my_component.js",
        "my_component.d.ts", # Optional.
    ],
    scripts = [":my_component_scripts"],
    deps = [":some_prerender_dep"],
)

js_library(
    name = "my_component_scripts",
    srcs = ["my_component_script.js"],
    deps = [":some_script_dep"],
)

# ...

// my_component.js

const { target } = require('./some_prerender_dep.js');

function renderComponent() {
    return `<div>Hello, ${target}!</div>`;
}

module.exports = { renderComponent };

// my_component.d.ts

declare function renderComponent(): string;

// my_component_script.js

import { target } from './some_script_dep';

console.log(`Hello, ${target}!`);

• Fixes #39 - Adds support for publishing prerender_component() targets to NPM. Adds prerender_component_publish_files() which, given a prerender_component() dependency, collects all the *.js and *.d.ts files that should be published to an external package manager (for example, NPM). These published files can be included in a pkg_npm() target to make sure all the required files are published. The published package can then also contain a prerender_component() using the published *.js and *.d.ts files to expose the component to consumers. Note that getting client-side scripts, styles, and resources to load correctly can be quite nuanced and attempting to do so will likely result in a lot of hair-pulling. See Declarative Shadow DOM for an example of a published component.

# BUILD.bazel (of `my_package` repository)

load("@build_bazel_rules_nodejs//:index.bzl", "pkg_npm")
load("@npm//rules_prerender:index.bzl", "prerender_component", "prerender_component_publish_files")

prerender_component(
    name = "my_component",
    srcs = ["my_component.ts"],
    # ...
)

# Includes `my_component.js`, as well as any client-side scripts, styles, or resources used in the component.
prerender_component_publish_files(
    name = "my_component_publish_files",
    dep = ":my_component",
)

# Generates a package with:
# /package.json
# /my_component.js
pkg_npm(
    name = "pkg",
    package_name = "my_package",
    deps = [
        "package.json",
        "BUILD", # Build file published to NPM and used by consumers.
        ":my_component_publish_files",
    ],
)

# BUILD (of `my_package` repository)
# A `BUILD.bazel` file that is shipped to NPM and used by consumers under `@npm//my_package`.
# Has access only to published sources.

load("@npm//rules_prerender:index.bzl", "prerender_component")

prerender_component(
    name = "my_component",
    srcs = ["my_component.js"], # Use published JS.
    visibility = ["//visibility:public"],
)

Now consumers can use your published component like so:

# BUILD.bazel (of consumer's repository, trying to use published `:my_component`)

load("@npm//rules_prerender:index.bzl", "prerender_component")

prerender_component(
    name = "my_app_component",
    srcs = ["my_app_component.ts"],
    deps = ["@npm//my_package:my_component"], # Use the published component just like any other.
)

• Fixes #38 - Adds Declarative Shadow DOM component. This is used to polyfill Declarative Shadow DOM for browsers that don't yet support it. See //examples/declarative_shadow_dom/... for a complete example. General usage pattern is like so:

# BUILD.bazel

load("@npm//rules_prerender:index.bzl", "prerender_component")

prerender_component(
    name = "my_component",
    srcs = ["my_component.ts"],
    lib_deps = ["@npm//rules_prerender"],
    styles = ["my_styles.css"],
    deps = ["@npm//rules_prerender;declarative_shadow_dom"],
)

// my_component.ts

import { inlineStyle } from 'rules_prerender';
import { polyfillDeclarativeShadowDom } from 'rules_prerender/declarative_shadow_dom';

export async function renderComponent(content: string): string {
    return `
        <!-- Host element. -->
        <div>
            <!-- Shadow root. -->
            <template shadowroot="open">
                <!-- Polyfill declarative shadow DOM for browsers that don't support it yet. -->
                ${polyfillDeclarativeShadowDom()}

                <!-- Inline styles to apply them within this shadow root. -->
                ${await inlineStyle('rules_prerender/examples/declarative_shadow_dom/component.css')}

                <!-- Shadow DOM content, styled with the associated style sheet. -->
                <div>Shadow content</div>

                <!-- Slot to insert the associated light DOM. -->
                <slot></slot>
            </template>

            <!--
                Light DOM content, inserted into the above slot, but not affected by above style sheet.
                **Highly-recommended** to never insert input DOM under the shadow root, or it will be affected by styles.
                Always use a <slot></slot> and drop input into the light DOM, so CSS works as expected.
            -->
            ${content}
    `;
}

/* my_styles.css */

/**
 * Because this sheet is included in a shadow root, we can use very broad selectors like `div` and trust that they
 * will be scoped only to the component DOM. Only "Shadow content" will be red, input from `content` will never
 * be red, even if it contains a `<div />` tag.
 */
div {
    color: red;
}

0.0.9

https://www.npmjs.com/package/rules_prerender/v/0.0.9

Changelog:

• #28 - Adds prerender_resources(). This macro is useful for generating files without the overhead of processing and bundling them as complete HTML web pages. See example.

0.0.8

https://www.npmjs.com/package/rules_prerender/v/0.0.8

Changelog:

• Fixes #22 - Adds a validation action to web_resources(), ensuring that a merge conflict in a web_resources() target will break the offending target instead of a downstream one. Requires the --experimental_run_validations flag.
• 11f6e92 - Adds tags attribute to web_resources_devserver().

0.0.7

https://www.npmjs.com/package/rules_prerender/v/0.0.7

Changelog:

BREAKING CHANGES:

• c414b05 - Renames prerender_multi_page_bundled() to prerender_pages().
• 830bf8f - Renames prerender_multi_page() to prerender_pages_unbundled().

Other changes:

• Fixes #10 - Adds %{name}_prerender_for_test target to prerender_component(), prerender_pages(), and prerender_pages_unbundled(). This provides a testonly reference to the prerender ts_library() and allows for simple unit tests of prerender source code. See the counter component for example usage.

0.0.6

https://www.npmjs.com/package/rules_prerender/v/0.0.6

Changelog:

BREAKING CHANGES:

• Refs #24 - Removed prerender_page_bundled(). Users should migrate to use prerender_multi_page_bundled(), just returning a single PrerenderResource object.
• Refs #24 - Removes prerender_page(). Users should migrate to use prerender_multi_page(), just returning a single PrerenderResource object. If a label referring to the generated file is desriable for post-processing, users should leverage extract_single_resource() to convert the generated directory of one file into a pre-determined label referring to that file.

Other changes:

• Refs #24 - Adds extract_single_resource(). This accepts a web_resources()-compatible target which contains exactly one file and extracts that file to a predetermined label. This makes it easier to post-process generated files with tools that expect a single input file rather than a directory. See extract_single_resource() docstring for more info and an example use case.

0.0.5

https://www.npmjs.com/package/rules_prerender/v/0.0.5

Changelog:

• Fixes #24 - Adds a data attribute to prerender_*() macros. This allows prerender code to depend on data files and read them from the runfiles tree during execution. See Generating multiple pages.

0.0.4

https://www.npmjs.com/package/rules_prerender/v/0.0.4

Changelog:

• Fixes #1 - Adds and prerender_multi_page_bundled(). Users can generate multiple files and trust tooling to automatically bundle and inject the relevant JavaScript and CSS. See project README for more information.