labb-provides.yaml is how a package publishes CSS to labb projects. A package ships this file at its root; consumers then subscribe to its named groups from their own css.packages, instead of hardcoding the package's template paths.
This is the reference for the file. For a walkthrough of building a package, see Developing packages.
Location
The file lives at the package root, the directory that contains the package's __init__.py:
my_package/
__init__.py
labb-provides.yaml ← here
templates/
css/
labb finds it by importing the package (import my_package) and reading labb-provides.yaml next to its __file__. This works whether the package is a path dependency or installed from PyPI. The consumer never needs to know where it lives on disk.
Schema
provides:
<group-name>:
components: [<glob>, ...] # optional
literals: [<glob>, ...] # optional
imports: [<path>, ...] # optional
provides: a mapping of group name to its contributions. A consumer selects groups by name (my_package: [group-a, group-b]),'*'(or theallalias, or blank) for every group.- Every path is relative to the package root and resolved at build time.
The three contribution kinds
| Key | What it does | Use for |
|---|---|---|
components |
Template globs scanned for <c-lb.*> usage; their variant classes are added to the safelist. |
Templates that use labb components, so the dynamic classes (btn-primary, badge-lg) compile. |
literals |
Template globs handed to Tailwind as @source. |
Templates with raw utility classes written literally in the markup (e.g. min-h-screen, -translate-x-1/2) that Tailwind must scan directly. |
imports |
CSS files shipped in the package, inlined into the build. | Themes and other package CSS. Inlined (not @imported) so any @plugin inside resolves against the consumer's node_modules. |
A group may set any combination of the three. See Building CSS for why components and literals are separate.
Example: labb's own file
The labb package publishes these groups:
provides:
themes:
imports: [css/themes.css]
components:
components: [templates/cotton/lb/**/*.html]
literals: [templates/cotton/lb/**/*.html]
reactivity:
components: [templates/cotton/lbr/**/*.html]
literals: [templates/cotton/lbr/**/*.html]
blocks:
components: [templates/cotton/lbb/**/*.html]
literals: [templates/cotton/lbb/**/*.html]
examples:
components: [templates/lb-examples/**/*.html]
literals: [templates/lb-examples/**/*.html]
A consumer picks what it needs:
# labb.yaml
css:
packages:
labb: [themes, components] # a normal app
# labb: '*' # everything (the docs site does this)
Resolution and merging
- Selected groups are merged.
components,literals, andimportslists are concatenated with order-preserving de-duplication, so two groups that share an import (e.g. both pullthemes) inline it only once. - If a consumer names a group the package does not publish, the build fails with a clear error listing the available groups.
- If a consumer subscribes by group to a package that ships no
labb-provides.yaml, the build fails and points you at the raw-mapping form instead.
my_package: { literals: [templates/*/.html] }. Groups are the ergonomic layer on top.