labb 0.5.0 is out

labb-provides.yaml

labb-provides.yaml reference: publish named CSS groups (components, literals, imports) from a Python package so labb projects can subscribe by name.

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 the all alias, 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, and imports lists are concatenated with order-preserving de-duplication, so two groups that share an import (e.g. both pull themes) 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.