Manifest Attribute

data-luis-manifest is a separate attribute used to set compile mode and execution strategy per source. It is not a data-luis value — it can be used together with data-luis.

<link
  rel="stylesheet"
  href="./styles.luis"
  data-luis="performance"
  data-luis-manifest="/lenty-hybrid.json"
>

What Is Its Purpose?

The purpose of this attribute is to be able to give different runtime decisions to different .luis sources on the same page.

For example:

running a vendor-heavy file with a lighter compile mode
forcing a large source onto the worker path
leaving the default auto decision for some sources while explicitly overriding others

In short, data-luis-manifest provides a centralized runtime decision table per source.

When Should It Be Used?

It makes sense to use it in these situations:

If there are multiple .luis sources on the page and they won't all use the same runtime path
If a specific mode like vendor-fast needs to be enforced for some sources
If you want to collect the worker / main / auto decision in a central manifest file instead of distributing it over individual HTML attributes
If you want to reuse the same decision set across multiple pages or sources

It is usually not needed in these situations:

if you have only one .luis source
if simple direct attribute usage like data-luis="lazy,worker" is sufficient
if there is no need for different mode/execution between sources

Practical rule:

data-luis for a few simple options
data-luis-manifest for per-source centralized overrides

Manifest v1 Format

The manifest file is JSON format:

{
  "version": 1,
  "rules": [
    {
      "matchType": "suffix",
      "value": "/vendor/bootstrap.luis",
      "mode": "vendor-fast",
      "execution": "worker"
    }
  ]
}

Each rule inside rules can carry mode, execution, or both.

Field Reference

Top Level

Field	Type	Description
`version`	`number`	Manifest format version — currently `1`
`rules`	`array`	Array of match rules

Rule Fields

Field	Values	Description
`matchType`	`"suffix"`	Match rule type
`value`	`string`	Match value
`mode`	`"full"`, `"vendor-fast"`	Compile mode override
`execution`	`"auto"`, `"main"`, `"worker"`	Execution path override

The mode and execution fields are each optional independently — but at least one must be present in a rule.

Field Values

`matchType: "suffix"`

Performs endsWith(value) matching against the sourceId. Query and hash parts are stripped first.

{ "matchType": "suffix", "value": "/vendor/bootstrap.luis" }

`mode`

Value	Description
`full`	Normal full compiler pipeline. The safe path if `.luis`-specific syntax is present.
`vendor-fast`	A lighter path for CSS/vendor-heavy sources. Skips preprocessing steps like `@fun`, `@for`. If the source requires `.luis` syntax, the runtime automatically falls back to `full`.

`execution`

Value	Description
`auto`	The runtime decides heuristically whether to use the main thread or worker
`main`	Forces compilation on the main thread
`worker`	Forces the worker path; falls back to main thread if worker is unavailable

Additional Examples

Mode override only:

{
  "version": 1,
  "rules": [
    {
      "matchType": "suffix",
      "value": "/vendor/bootstrap.luis",
      "mode": "vendor-fast"
    }
  ]
}

Execution override only:

{
  "version": 1,
  "rules": [
    {
      "matchType": "suffix",
      "value": "/interactive/dashboard.luis",
      "execution": "worker"
    }
  ]
}

Security Boundary (Manifest URL)

The data-luis-manifest URL is also subject to the runtime URL policy.

Default behavior:

same-origin manifest URL is required
empty, unparseable, or dangerous scheme URLs (javascript:, data:, etc.) are rejected
cross-origin manifest is only accepted with an explicit policy override

Detailed example:

<script>
  window.__LentyStyleSecurityPolicy = {
    // Default is false; here as an example allowing cross-origin manifest.
    allowCrossOriginManifest: true,
  };
</script>

<link
  rel="stylesheet"
  href="/styles/app.luis"
  data-luis="performance"
  data-luis-manifest="https://cdn.example.com/lenty-hybrid.json"
>

Explanation:

If allowCrossOriginManifest is not defined or is false, the manifest URL above is rejected.
When allowCrossOriginManifest: true is provided, a manifest fetch is attempted.
If the manifest cannot be loaded, compilation is not entirely broken; it continues with normal flow without applying the override.

Behavior

If a rule matches, the mode and execution overrides are applied
If no match, auto-detect takes over
mode and execution are resolved separately; for each, the first matching rule returns the relevant override
An invalid or inaccessible manifest does not stop compilation; a warning is logged if debug=true
Invalid rules in the rules array are ignored and an invalid-manifest warning is produced
The manifest file is cached by its resolved absolute URL; when the same manifest is requested again, the existing load result is reused