Migrate preview and docs packages from Eleventy to Astro (#2694)

Co-authored-by: Bartek <xbartoszdobija@gmail.com>

.agents/rules/docs.mdc

@@ -0,0 +1,80 @@
+---
+description: Tabler docs package rules (Astro, MDX documentation pages)
+globs: docs/**
+alwaysApply: false
+---
+
+# Tabler docs (@tabler/docs)
+
+## Development
+
+When starting the dev server, use background mode:
+
+```
+astro dev --background
+```
+
+Manage the background server with `astro dev stop`, `astro dev status`, and `astro dev logs`.
+
+## Documentation
+
+Full documentation: https://docs.astro.build
+
+Consult these guides before working on related tasks:
+
+- [Adding pages, dynamic routes, or middleware](https://docs.astro.build/en/guides/routing/)
+- [Working with Astro components](https://docs.astro.build/en/basics/astro-components/)
+- [Using React, Vue, Svelte, or other framework components](https://docs.astro.build/en/guides/framework-components/)
+- [Adding or managing content](https://docs.astro.build/en/guides/content-collections/)
+- [Adding styles or using Tailwind](https://docs.astro.build/en/guides/styling/)
+- [Supporting multiple languages](https://docs.astro.build/en/guides/internationalization/)
+
+## Writing documentation pages
+
+Pages live in `pages/**/*.mdx`. Use the flat convention: leaf pages are `foo.mdx`; only pages with sub-pages use `foo/index.mdx` (both render as `/foo/`).
+
+- Write in simple English: short sentences, common words, direct verbs (`Use`, `Add`, `Set`).
+- Component docs use singular naming in frontmatter and filename: `title: Card`, `card.mdx` (not `cards.mdx`).
+- Do not add meta authoring notes (e.g. "this snippet is copy-paste ready").
+
+### Frontmatter
+
+Static YAML only. Required keys plus the layout:
+
+```yaml
+---
+title: Alert
+summary: Short one-sentence summary of what this component does.
+description: Practical description of when and why to use it.
+layout: '@shared/layouts/DocsMdxLayout.astro'
+---
+```
+
+Optional: `bootstrapLink: components/alerts/` when the component extends a Bootstrap component.
+
+### Examples
+
+Import shared components after the frontmatter and wrap previews in `Example`:
+
+```mdx
+import Example from '@shared/components/docs/Example.astro';
+import Alert from '@shared/components/Alert.astro';
+
+<Example>
+<Alert type="success" title="Wow!" description="Your account has been saved!" />
+</Example>
+```
+
+- Add 1-2 short sentences before each `Example` describing what the preview shows.
+- `Example` props: `hideCode` (visual-only preview), `code` (override the displayed snippet), `centered`, `vertical`, `column` (narrow ~25rem column), `raw` (no preview wrappers), `bg="dark"` (background), `height`, `codeOnly`.
+- Raw HTML in an `Example` slot is reserialized by MDX — keep example markup on single lines next to tags to avoid stray `<p>` wrapping.
+
+### Structure
+
+Recommended `##` section order: `Overview`, `Installation` (optional), `Variants` (components) or `Usage` (utilities/workflows), `Accessibility`, `Examples` (optional), `SCSS variables` (optional), `Migration notes` (optional). Keep heading hierarchy consistent (`##` then `###`), use stable descriptive headings.
+
+### Checklist
+
+- Documented classes exist in `core/scss/` sources; do not document internal-only or removed classes.
+- Interactive examples include accessibility attributes (`aria-label`, semantic markup).
+- Verify examples render (`pnpm --filter @tabler/docs build`) and links work.

.agents/rules/main.mdc

@@ -0,0 +1,102 @@
+---
+description: Tabler Project Rules
+globs:
+alwaysApply: true
+---
+
+
+# Tabler — project rules
+
+Shared instructions for all AI agents (Claude Code, Cursor, etc.). Canonical agent configuration lives in `.agents/` (`rules/` + `skills/`); `.claude/skills` is a symlink into it.
+
+## Project structure
+
+- `core/` — `@tabler/core`: SCSS sources (`core/scss/`), JS, the distributable framework.
+- `preview/` — `@tabler/preview`: demo site built with Astro (pages in `preview/pages/*.astro`).
+- `docs/` — `@tabler/docs`: documentation site built with Astro (pages in `docs/pages/**/*.mdx`); docs-specific rules: `.agents/rules/docs.mdc`.
+- `shared/astro/` — Astro components, layouts, and lib shared by `preview` and `docs` (imported via the `@shared` alias).
+- `shared/data/` — JSON data used by pages (imported via the `@data` alias).
+- Package manager: pnpm workspaces + turbo. Node.js >= 22.12.
+
+## Language
+
+- Write all repository content in English: code, comments, documentation, commit messages, PR titles and descriptions.
+- Use simple English in documentation: short sentences, common words, direct instructions.
+
+## HTML and component guidelines
+
+### Astro pages and components
+
+- Pages are Astro components; reusable markup lives in `shared/astro/components/`.
+- Icons: use the shared component — `<Icon name="home" />` (import from `@shared/components/Icon.astro`).
+- Links between preview pages are relative: `./job-listing.html` (root-level pages).
+- Boolean HTML attributes in Astro: `selected={true}` renders a bare attribute, but some attributes (e.g. `multiple`) render `="true"` — use `multiple ? '' : undefined` when a bare attribute is required.
+
+### CSS classes
+
+- Use Bootstrap 5 classes plus Tabler's custom classes.
+- Follow Tabler's CSS custom properties pattern: `--#{$prefix}component-property`.
+- Cards: `card` for containers, `card-body` for content, `card-header` / `card-title` for headers.
+- Buttons: `btn` for all buttons; `btn-primary` for primary actions; plain `btn` for secondary actions (do not use `btn-outline-secondary`); `btn-sm` for small buttons; `w-100` for full width.
+- Forms: `form-control` for inputs, `form-label` for labels, `form-check` for checkboxes/radios, `form-select` for dropdowns.
+- Layout: Bootstrap grid (`row`, `col-*`), `container-xl` for main containers, `page-wrapper` / `page-body` for page structure.
+- Badges: plain `badge` class; do not use `badge-outline` or `badge-primary`; do not change badge text color.
+- Markdown content: wrap in a `markdown` class container.
+
+### Accessibility
+
+- Use semantic HTML elements and proper heading hierarchy.
+- Include ARIA labels (e.g. `aria-label` for icon-only buttons) and alt text for images.
+
+## SCSS guidelines
+
+- Use semantic class names that describe purpose, not appearance.
+- Keep Bootstrap-compatible class naming conventions.
+- Group related styles together with clear comments; keep consistent spacing and indentation.
+
+## Git conventions
+
+### Branch naming
+
+- Lowercase, kebab-case, format: `<type>/<short-description>` or `<type>/<issue-id>-<short-description>` (issue id as `gh-123`, never `#`).
+- Allowed types: `feat`, `fix`, `docs`, `chore`, `refactor`, `test`, `build`, `ci`, `perf`, `style`, `revert`.
+- Examples: `feat/gh-123-add-stepper-component`, `fix/markdown-table-overflow`.
+- Branch off `dev` by default.
+
+### Commit messages
+
+- English, conventional commit format when possible: `feat: add progress steps component`, `fix: update icon stroke width for better visibility`.
+
+### Pull requests
+
+- Title in English, capitalized, present tense, ideally <= 72 chars, no trailing period.
+- Description in English, skimmable (bullets, short paragraphs), focused on **why** the change is needed and its user-visible effect. Recommended template:
+
+  ```md
+  ## Summary
+  - <1-3 bullets describing the change and why>
+
+  ## Changes
+  - <key implementation notes, non-obvious decisions>
+  ```
+
+- Mark WIP PRs as drafts.
+
+### Changesets
+
+- Each change gets a separate file in `.changeset/` with a descriptive kebab-case filename (e.g. `progress-sizes.md`).
+- One sentence per changeset, starting with an action verb (`Added`, `Updated`, `Fixed`, `Removed`), with backticks for code elements (`.btn-ghost`, `stroke-width`, `1.5`, `arrow-up`).
+- Version bumps: **major** = breaking changes; **minor** = new features, components, or pages; **patch** = bug fixes, small improvements, style/accessibility tweaks.
+- Packages: `"@tabler/core"` for SCSS/JS/classes, `"@tabler/preview"` for demo pages, `"@tabler/docs"` for documentation; list multiple packages when the change spans areas.
+- Example:
+
+  ```md
+  ---
+  "@tabler/core": minor
+  "@tabler/preview": minor
+  ---
+
+  Added Progress Steps component for step-by-step navigation indicators.
+  ```
+
+- If a PR changes SCSS or any package behavior, it must include a changeset.

.agents/skills/write-docs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: write-docs
-description: Write or update Tabler documentation pages in simple English using the current docs schema. Use when the user asks to create docs, edit docs, add new feature docs to an existing page, or standardize docs structure across any docs/content category.
+description: Write or update Tabler documentation pages in simple English using the current docs schema. Use when the user asks to create docs, edit docs, add new feature docs to an existing page, or standardize docs structure across any docs category.
 disable-model-invocation: true
 ---
 
@@ -10,7 +10,7 @@ Write docs directly in files (do not stop at draft mode) and follow the current
 
 ## 1. Scope and behavior
 
-- Works for any docs page type under `docs/content/**` (components, utilities, forms, layout, plugins, base, getting started, emails, illustrations, icons, index pages).
+- Works for any docs page type under `docs/pages/**` (components, utilities, forms, layout, plugins, base, getting started, emails, illustrations, icons, index pages). Pages are MDX: leaf pages `foo.mdx`, parents with sub-pages `foo/index.mdx`.
 - Edit existing pages when the user asks to document new functionality in an existing component/page.
 - Create new pages when needed.
 - Use simple English in all prose.
@@ -32,14 +32,15 @@ Default frontmatter (required unless user asks otherwise):
 title: ...
 summary: ...
 description: ...
+layout: '@shared/layouts/DocsMdxLayout.astro'
 ---
 ```
 
 Rules:
 
 - Keep frontmatter static YAML only.
-- By default, include only `title`, `summary`, and `description`.
+- By default, include only `title`, `summary`, `description`, and `layout`.
-- Add extended keys (for example `order`, `plugin`, `docs-libs`, `layout`, `redirect`, `related`, `source-scss`, `bootstrap-url`, `classnames`) only when the user explicitly asks for them.
+- Add extended keys (for example `bootstrapLink`, `order`, `plugin`, `docs-libs`, `redirect`) only when the user explicitly asks for them or nearby pages in the same category use them.
 
 ## 4. Documentation schema to follow
 
@@ -62,22 +63,25 @@ Guidance by page type:
 
 ## 5. Example and snippet pattern
 
-For visual examples, use project includes:
+For visual examples, use the shared `Example` component (import after the frontmatter):
+
+```mdx
+import Example from '@shared/components/docs/Example.astro';
+
+<Example>
+<button class="btn btn-primary">Primary button</button>
+</Example>
+```
 
-- Wrap preview markup with:
-  - `{% capture html -%} ... {%- endcapture %}`
-  - `{% include "docs/example.html" html=html %}`
 - Add 1-2 short sentences before each preview block to explain what the preview shows.
-- Use include options when useful: `hide-code`, `separated`, `centered`, `vertical`, `raw`, `column`, `bg`.
+- Use props when useful: `hideCode`, `centered`, `vertical`, `raw`, `column`, `bg`, `height`, `codeOnly`.
-- For examples with cleaner source markup, also add:
+- For a cleaner displayed snippet than the rendered preview, pass `code={...}`.
-  - `{% capture code -%} ... {%- endcapture %}`
+- For icons and other shared components inside examples, import them from `@shared/components/` (for example `<Icon name="plus" />`).
-  - `{% include "docs/example.html" html=html code=code %}`
+- Raw HTML in the `Example` slot is reserialized by MDX — keep markup lines attached to tags to avoid stray `<p>` wrapping.
-- For icons inside examples, use:
-  - `{% include "ui/icon.html" icon="icon-name" %}`
 
 ## 6. Workflow for each request
 
-1. Identify target file(s) in `docs/content/**`.
+1. Identify target file(s) in `docs/pages/**`.
 2. Read the target page and 2-3 nearby pages in the same category to match tone and conventions.
 3. Apply the schema from section 4.
 4. Write/update the page directly in file(s).
@@ -96,8 +100,8 @@ For visual examples, use project includes:
 
 - [ ] Uses simple English.
 - [ ] Frontmatter uses static YAML.
-- [ ] Default frontmatter contains only `title`, `summary`, `description` (unless user requested extra keys).
+- [ ] Default frontmatter contains only `title`, `summary`, `description`, `layout` (unless user requested extra keys).
 - [ ] Follows schema and heading hierarchy.
-- [ ] Examples use `docs/example.html` pattern where applicable.
+- [ ] Examples use the `Example` component pattern where applicable.
 - [ ] Accessibility section exists for interactive UI docs.
 - [ ] No mention of changeset reminders unless user asks.

.build/zip-package.ts

@@ -22,7 +22,7 @@ const zip = new AdmZip()
 zip.addLocalFolder(path.join(__dirname, '../preview/dist'), 'dashboard')
 
 zip.addLocalFile(
-	path.join(__dirname, '../preview/static', 'og.png'),
+	path.join(__dirname, '../shared/static', 'og.png'),
 	'.',
 	'preview.png'
 )

.changeset/astro-migration.md

@@ -0,0 +1,6 @@
+---
+"@tabler/preview": minor
+"@tabler/docs": minor
+---
+
+Updated the `preview` and `docs` packages to build with Astro instead of Eleventy, keeping the generated pages identical and moving shared components to `shared/astro/`.

.claude/agents/astro-components.md

@@ -0,0 +1,98 @@
+---
+name: astro-components
+description: Builds new Astro components, pages, and layouts for the Tabler monorepo (preview and docs packages, shared/astro library). Use when creating or extending demo pages, UI components, cards, layouts, or docs examples. Knows the project's component conventions, script/modal architecture, and shared building blocks.
+---
+
+You are a specialist in building Astro components and pages for Tabler.
+
+## Architecture
+
+- `shared/astro/` is the single component library used by both site packages:
+  `components/` (UI + cards + parts), `layouts/`, `lib/`, `data/docs.json`.
+- `preview/` (`@tabler/preview`) — demo site; pages in `preview/pages/*.astro`
+  (`srcDir: '.'`, `build.format: 'file'` → `foo.astro` → `/foo.html`).
+- `docs/` (`@tabler/docs`) — documentation; pages in `docs/pages/**/*.mdx`
+  (`build.format: 'directory'`; docs writing rules: `.agents/rules/docs.mdc`).
+- Aliases (vite + tsconfig, per package): `@shared` → `../shared/astro`,
+  `@data` → `../shared/data`, `@pages` → the package's pages dir.
+  Inside `shared/astro`, use relative imports; from shared code to
+  package-specific files use the package aliases. Any bare npm import used in
+  `shared/astro` must be declared in `shared/astro/package.json`.
+
+## Component conventions
+
+- Components are `.astro` only; helper logic goes to `shared/astro/lib/*.ts`.
+- TypeScript frontmatter: `interface Props` + destructuring with defaults.
+- Props are camelCase; the `class` prop stays `class`
+  (destructure as `class: className`).
+- Inline `<style>`/`<script>` in markup ALWAYS with `is:inline` (otherwise
+  Astro adds `data-astro-cid-*` everywhere or bundles the script).
+  No scoped styles, no CSS imports in frontmatter.
+- Data that may contain markup or entities: render with `set:html`.
+  Entities in attribute strings: pass as expressions (`title={"...&hellip;"}`),
+  because JSX decodes entities in string literals.
+- Boolean attributes are inconsistent in Astro: `selected={true}` renders a
+  bare attribute, but some (e.g. `multiple`) render `="true"` — use
+  `multiple ? '' : undefined` when a bare attribute is required. Check
+  the built output when unsure.
+- Follow the HTML/CSS class guidelines in `.agents/rules/main.mdc`
+  (Bootstrap 5 + Tabler classes, buttons, badges, accessibility).
+
+## Building blocks — use, do not duplicate
+
+Read the `Props` interface of a component before using it; extend components
+additively instead of creating parallel variants.
+
+- `@shared/components/Icon.astro` — `<Icon name="eye" size="sm" class="..." />`.
+- `@shared/components/Button.astro` — full button API (color, outline, ghost,
+  size, icon, iconOnly, dismiss, loading, modalId, ...).
+- `@shared/components/Chart.astro` + `@shared/lib/chart-script.ts` — ApexCharts
+  engine driven by `@data/charts.json`. Never hand-write chart configs; add
+  fields to `chart-script.ts` if a new chart needs them.
+- `@shared/components/ui/*` — Avatar, Badge, Progress, Pagination, Flag,
+  Dropdown, Table, Steps, Nav, Spinner, and ~45 more.
+- `@shared/components/cards/*` — dashboard/demo cards.
+- Layouts in `@shared/layouts/`: `BaseLayout` (head, assets, theme settings),
+  `DefaultLayout` (navbar/sidebar page chrome; props for navbar variants,
+  wrapper/container classes, page header), `SingleLayout` (auth pages),
+  `ErrorLayout`, `SettingsLayout`, `MarketingLayout`, `PayLayout`,
+  `DocsLayout`/`DocsMdxLayout` (docs).
+- Docs examples: `@shared/components/docs/Example.astro` (slot or `html` prop;
+  props: hideCode, code, centered, vertical, column, raw, bg, height, codeOnly).
+
+## Page scripts and modals
+
+- Register per-page scripts with `addPageScript()` and modals with
+  `addPageModal()` (`@shared/lib/page-scripts.ts` / `page-modals.ts`).
+  Registration MUST be synchronous in the component frontmatter (before the
+  first `await`) — Astro renders siblings concurrently, and a registration
+  after `await Astro.slots.render()` loses the race against the drain in
+  `PageScripts`/`PageModals` (emitted by `BaseLayout`).
+- Script-emitting components also render `<InlineScript code={script} />`.
+  Its behavior is chosen per package by the vite define
+  `import.meta.env.INLINE_PAGE_SCRIPTS`: preview drains registered scripts at
+  the end of the page; docs inlines them next to the example.
+- Third-party page libraries: list names in the layout's `pageLibs` prop —
+  resolved via `@tabler/core/libs.json` (a full `http` URL in there is emitted
+  verbatim; `head: true` libs go into `<head>`).
+
+## Data
+
+- JSON data: import from `@data/*.json` (single source of truth in
+  `shared/data/`). Site config: `site` from `@shared/lib/site.ts` (but pages
+  that feed theme colors to charts import `@data/site.json` directly — the two
+  have different `themeColors` semantics).
+- Deterministic pseudo-randomness for demo content (photos, dates): derive from
+  an index prop, never from `Math.random()`.
+
+## Workflow for a new preview page
+
+1. Create `preview/pages/<name>.astro`; pick the layout (usually
+   `DefaultLayout`) and pass `title`, menu/page-header props, `pageLibs`.
+2. Compose from existing components; add new ones to `shared/astro/components/`.
+3. Build and verify: `pnpm --filter @tabler/preview build` (output in
+   `preview/dist/<name>.html`), or `astro dev` for live preview.
+4. If the page should appear in navigation, update `@data` menu sources.
+
+Final report: list created/modified files, prop signatures of new components,
+and any assumptions or open questions.

.claude/skills

@@ -0,0 +1 @@
+../.agents/skills

.cursor/rules/branch-naming.mdc

@@ -1,38 +0,0 @@
----
-description: Git Branch Naming Rules
-globs:
-alwaysApply: true
----
-
-## Branch naming
-
-- Use lowercase branch names.
-- Use a type prefix and a short description in kebab-case.
-- Format: `<type>/<short-description>` or `<type>/<issue-id>-<short-description>`
-- Use `gh-123` as the issue id format (avoid `#` in branch names).
-
-### Allowed types
-
-- `feat` - new features
-- `fix` - bug fixes
-- `docs` - documentation changes
-- `chore` - maintenance / tooling
-- `refactor` - code refactoring (no behavior change)
-- `test` - tests only
-- `build` - build system changes
-- `ci` - CI changes
-- `perf` - performance improvements
-- `style` - formatting / lint-only changes
-- `revert` - reverting prior changes
-
-### Examples
-
-- `feat/gh-123-add-stepper-component`
-- `fix/markdown-table-overflow`
-- `docs/gh-45-update-contributing`
-- `chore/update-pnpm-lock`
-
-### Notes
-
-- Branch off `dev` by default (unless maintainers request otherwise).
-- Avoid spaces, uppercase letters, and special characters other than `/` and `-`.

.cursor/rules/changelog.mdc

@@ -1,100 +0,0 @@
----
-description: Cursor Rules for Tabler Changesets
-globs:
-alwaysApply: true
----
-
-
-### File Structure
-
-- Each change must be in a separate changeset file in `.changeset/` directory
-- Use descriptive kebab-case filenames (e.g., `progress-sizes.md`, `button-ghost.md`)
-- Follow the standard changeset format with frontmatter and description
-
-### Change Description Format
-
-- **One sentence per changeset** - keep descriptions concise and focused
-- Use **backticks for code elements**: classes (`.btn-ghost`), properties (`stroke-width`), values (`1.5`), icons (`arrow-up`)
-- Start with action verbs: "Added", "Updated", "Fixed", "Removed"
-- Be specific about what was changed
-
-### Version Bump Guidelines
-
-- **Major**: Breaking changes, complete rewrites
-- **Minor**: New features, new components, new pages, significant enhancements
-- **Patch**: Bug fixes, small improvements, style updates, accessibility fixes
-
-### Package Selection
-
-- `"@tabler/core"`: Changes to SCSS, core functionality, CSS classes
-- `"@tabler/preview"`: New pages, demo updates, preview-specific changes
-- `"@tabler/docs"`: Documentation updates
-- Use multiple packages when change affects multiple areas
-
-### Examples
-
-#### New Feature (Minor)
-
-```md
----
-"@tabler/core": minor
-"@tabler/preview": minor
----
-
-Added Progress Steps component for step-by-step navigation indicators.
-```
-
-#### Bug Fix (Patch)
-
-```md
----
-"@tabler/core": patch
----
-
-Updated `stroke-width` for `.icon-sm` from `1` to `1.5` for better visibility.
-```
-
-#### New Page (Minor)
-
-```md
----
-"@tabler/preview": minor
----
-
-Added new onboarding page with progress indicator and navigation layout.
-```
-
-#### Style Enhancement (Patch)
-
-```md
----
-"@tabler/core": patch
----
-
-Added smooth transitions for progress bar width and background color changes.
-```
-
-### Code Formatting Rules
-
-- Class names: `.btn-ghost`, `.progress-lg`, `.icon-sm`
-- CSS properties: `stroke-width`, `background-color`, `width`
-- Values: `1.5`, `transparent`, `100%`
-- Icon names: `arrow-up`, `arrow-down`, `trending-up`
-- HTML attributes: `aria-label`, `role`, `data-*`
-- JavaScript functions: `addEventListener()`, `querySelector()`
-
-### Common Patterns
-
-- **Component additions**: "Added [ComponentName] component for [purpose]"
-- **Size variants**: "Added [size] size variant for [component] (`.class-size`)"
-- **Style fixes**: "Fixed [issue] in [component/element]"
-- **Icon updates**: "Updated [component] to use `new-icon` instead of `old-icon`"
-- **Accessibility**: "Improved accessibility by [specific change]"
-
-### Commit Message Format
-
-Use English for commit messages following conventional commit format when possible:
-
-- `feat: add progress steps component`
-- `fix: update icon stroke width for better visibility`
-- `style: add smooth transitions to progress bars`

.cursor/rules/docs.mdc

@@ -1,341 +0,0 @@
----
-description: Markdown documentation writing standards for docs pages
-globs: docs/content/**/*.md
-alwaysApply: false
----
-
-# Markdown Documentation Rules
-
-## Scope
-
-- Apply these rules when creating or editing Markdown documentation files.
-- Write technical documentation in English.
-- Use simple English: short sentences, common words, and direct instructions.
-
-## Frontmatter
-
-- Use static YAML frontmatter only (no Liquid in frontmatter).
-- Include `title`, `summary`, and `description` for docs pages in `docs/content/**`.
-- For component docs, use singular naming in frontmatter and filename:
-  `title: Card`, `summary` and `description` written with a singular component form, and filename `card.md` (not `cards.md`).
-- Add optional frontmatter `related` entries (instead of a `Related` content section).
-- In `related`, always use absolute docs paths in `url` (without `./`), for example:
-  `ui/components/breadcrumb`.
-- Use this structure:
-  ```yaml
-  related:
-    - name: Pagination
-      url: ui/components/pagination
-    - name: Dropdowns
-      url: ui/components/dropdowns
-  ```
-- If documentation describes a component defined in SCSS, add `source-scss` with a relative path
-  inside `core/scss/` (for example: `source-scss: ui/buttons.scss`).
-- If a component extends a Bootstrap component, add `bootstrap-url: components/<name>` in frontmatter
-  (for example: `bootstrap-url: components/buttons`).
-- Add versioning notes for API and class lifecycle changes using fields like
-  `added-in: 1.4.0` and `deprecated-in: 1.2.0`.
-- If documentation introduces a new component, add a changeset with a `minor` version bump.
-- Components should include an optional `classnames` section in frontmatter.
-- Add only groups that exist for a given component. Do not include empty or irrelevant groups.
-- `classnames` entries must match classes that exist in the relevant SCSS source files.
-- Do not document classes that are not defined in SCSS, deprecated, or internal-only.
-- You can add `status` to class entries: `stable`, `deprecated`, or `experimental`.
-- If `status` is not provided, treat the class as `stable` by default.
-- Allowed `classnames` groups and meanings:
-  - `component`: Main component class.
-  - `modifier`: Modifies behavior of component or part.
-  - `part`: Part of a component.
-  - `style`: Visual style of component or part.
-  - `behavior`: Behavioural style of component or part.
-  - `color`: Color of component or part.
-  - `size`: Size of component or part.
-  - `placement`: Placement of component or part.
-  - `direction`: Direction of component or part.
-  - `variable`: CSS variable.
-  - `variant`: Use like `variant:utility` to apply a utility conditionally.
-- Use this structure:
-
-```yaml
-classnames:
-  component:
-    - class: btn
-      desc: Main button class
-  part:
-    - class: btn-group
-      desc: Group container for buttons
-  modifier:
-    - class: btn-block
-      desc: Full width button
-      status: stable
-  style:
-    - class: btn-outline
-      desc: Outline style button
-  behavior:
-    - class: btn-disabled
-      desc: Disabled visual state
-      status: deprecated
-  color:
-    - class: btn-primary
-      desc: Primary color button
-  size:
-    - class: btn-sm
-      desc: Small size button
-  placement:
-    - class: dropdown-menu-end
-      desc: Align dropdown menu to end
-  direction:
-    - class: carousel-vertical
-      desc: Vertical carousel direction
-  variable:
-    - class: --tblr-btn-padding-x
-      desc: Horizontal button padding variable
-  variant:
-    - class: hover:bg-primary
-      desc: Apply background color on hover
-      status: experimental
-```
-
-
-## Structure and readability
-
-- Start with a short purpose statement, then explain usage and variants.
-- Keep heading hierarchy consistent (`##` then `###`), without skipping levels.
-- Keep core documentation sections as `H2` headings in this order:
-  `Overview`, `Installation` (optional), `Variants` (for components that support variants or `Usage` for components that don't support variants), `Accessibility`,
-  `Examples` (optional), `SCSS variables` (optional), `Migration notes` (optional).
-- In `Overview`, add one visual component preview without code (`hide-code=true`).
-- Use descriptive section headings that are stable for linking.
-- Vary intro phrasing across pages; avoid repeating the same sentence pattern.
-
-## Markdown style
-
-- Follow `.markdownlint.json` conventions (ATX headings, `-` lists, fenced code blocks).
-- Keep line length within 120 characters where practical.
-- Keep examples aligned with current API/classes and practical usage.
-- Use active voice and direct verbs (`Use`, `Add`, `Set`).
-- Keep one main idea per sentence.
-- Do not add meta authoring notes in docs text (for example: "this snippet is copy-paste ready").
-
-## Terminology and section naming
-
-- Use consistent terminology across pages; one term per concept.
-- Use clear and consistent section names across component docs.
-- Prefer shared section labels such as `Overview`, `Accessibility`, `Examples` (optional), and `Migration notes`.
-- You can add an `SCSS variables` section for components with documented SCSS tokens/variables.
-
-### Recommended section order
-
-```md
-## Overview
-## Installation (optional)
-## Variants or Usage/API
-## Accessibility
-## Examples (optional)
-## SCSS variables (optional)
-## Migration notes (optional)
-```
-
-## Project-specific docs patterns
-
-- In docs examples, prefer `{% capture html %}...{% endcapture %}` and, when needed, add `{% capture code %}...{% endcapture %}` for code snippets.
-- Use `{% include "docs/example.html" ... %}` to render visual component previews in any relevant section
-  (`Overview`, `Variants`, `Usage/API`, or `Examples`).
-- Before each `{% include "docs/example.html" ... %}`, add 1-2 short sentences that describe
-  the component state or behavior shown in the preview.
-- For examples with explicit source snippets, use `{% include "docs/example.html" html=html code=code %}`.
-- For visual-only examples, use `{% include "docs/example.html" html=html hide-code=true %}`.
-- If an example shows multiple elements as a list, use `separated` to display items with clean spacing:
-  `{% include "docs/example.html" html=html separated %}`.
-- Add `centered` when the example should be centered (for example, a list of buttons):
-  `{% include "docs/example.html" html=html separated centered %}`.
-- If elements are wide, you can stack them vertically with `vertical` (for example):
-  `{% include "docs/example.html" html=html centered vertical %}`.
-- Use `raw` when you need to render the example without extra preview wrappers
-  (no padding, no centering), for example full page layout previews:
-  `{% include "docs/example.html" html=html raw %}`.
-- Use `column` to render content in a narrow column (about 25rem), useful for components
-  commonly presented in columns (for example stat cards):
-  `{% include "docs/example.html" html=html column %}`.
-- For `SCSS variables` sections, use:
-  `{% scss-docs "alert-variables" "ui/_alerts.scss" %}`.
-- This renders the fragment between `// scss-docs-start alert-variables` and `// scss-docs-end`
-  from the given SCSS file (path relative to `core/scss/`).
-- If an SCSS file contains a `scss-docs-start` block, it should be included in documentation
-  via a matching `{% scss-docs %}` entry.
-- Use `hide-code=true` only when source markup is not useful to the reader.
-- If an example needs a different background, set it with the include attribute `bg="surface-primary"`.
-- Treat `html` as the visual preview layer and `code` as the clean source layer shown to users.
-- Keep `code` concise and practical: include only the essential markup needed to explain usage.
-- Do not duplicate visual wrapper-only structure in `code` when it exists only to style the preview.
-- Do not promote deprecated patterns; when needed, mention the replacement.
-- Add accessibility attributes (for example `aria-label`) in interactive examples.
-
-## Publishing checklist
-
-- Verify that examples render correctly.
-- Verify that internal and external links work.
-- Verify heading hierarchy and section naming consistency.
-- Verify code snippets are accurate and minimal for the documented use case.
-- Validate documented classes against SCSS files before publishing.
-- Ensure every class in `classnames` maps to a real SCSS class or variable.
-- Ensure every class listed in `classnames` appears at least once in page content or examples.
-- For interactive components, add a short accessibility mini-check (`aria-label`, keyboard focus, semantic markup).
-
-## Documentation structure examples
-
-### Minimal component page structure
-
-```md
----
-title: Component name
-summary: Short one-sentence summary of what this component does.
-description: Practical description of when and why to use this component.
----
-
-## Overview
-
-One short paragraph explaining purpose and primary use case.
-
-Show the component in its default state so users can recognize it immediately.
-Keep this first example focused on appearance and context.
-
-{% capture html -%}
-<button class="btn btn-primary">Primary button</button>
-{% endcapture %}
-{% include "docs/example.html" html=html hide-code=true %}
-
-## Variants
-
-### Outline
-
-The outline variant presents a lighter visual emphasis than a filled primary action.
-Use it for secondary actions in dense interfaces.
-
-{% capture html -%}
-<button class="btn">Secondary</button>
-{% endcapture %}
-{% include "docs/example.html" html=html %}
-
-## Accessibility
-
-- Use clear labels for interactive controls.
-- Add `aria-label` for icon-only buttons.
-
-## Examples (optional, visual usage)
-
-### Default
-
-The default variant represents the primary action style.
-Use it as a baseline before introducing additional variants.
-
-{% capture html -%}
-<button class="btn btn-primary">Save</button>
-{% endcapture %}
-{% include "docs/example.html" html=html %}
-```
-
-### Visual preview patterns (usable in any section)
-
-```md
-## Variants
-
-### Default
-
-The default variant represents the primary action style.
-Use it as a baseline before introducing additional variants.
-
-{% capture html -%}
-<button class="btn btn-primary">Primary button</button>
-{% endcapture %}
-{% include "docs/example.html" html=html %}
-
-### With icon
-
-This variant combines a leading icon with a text label.
-Use it for actions that benefit from an additional visual cue.
-
-{% capture html -%}
-<button class="btn btn-primary">
-  {% include "ui/icon.html" icon="plus" %}
-  Add item
-</button>
-{% endcapture %}
-{% include "docs/example.html" html=html %}
-
-### Custom background
-
-This variant presents the component on a dark background surface.
-Use it to verify contrast and visual hierarchy.
-
-{% capture html -%}
-<button class="btn btn-light">Light button on dark preview</button>
-{% endcapture %}
-{% include "docs/example.html" html=html bg="dark" %}
-```
-
-```md
-## Usage
-
-Use this pattern in any section when source markup should be shown together with the visual output.
-Use `code` for clean implementation markup without preview-only wrappers.
-
-### Card with footer actions
-
-This example presents a card layout with footer actions in a realistic container.
-Show `html` for rendered context and `code` for implementation markup.
-
-{% capture html -%}
-<div class="p-4 border rounded bg-light">
-  <div class="card">
-    <div class="card-body">Content</div>
-    <div class="card-footer">
-      <button class="btn btn-primary">Save</button>
-    </div>
-  </div>
-</div>
-{% endcapture %}
-
-{% capture code -%}
-<div class="card">
-  <div class="card-body">Content</div>
-  <div class="card-footer">
-    <button class="btn btn-primary">Save</button>
-  </div>
-</div>
-{% endcapture %}
-{% include "docs/example.html" html=html code=code %}
-```
-
-```md
-## Accessibility
-
-Use this pattern in any section only for visual comparison cases where raw markup is not useful,
-for example screenshots, behavior notes, or before/after UI states.
-
-This pattern highlights visual state communication without extra source details.
-Use it for quick comparisons such as status, before/after states, or behavior notes.
-
-{% capture html -%}
-<div class="d-flex align-items-center gap-2">
-  <span class="badge bg-green"></span>
-  <span>Active status</span>
-</div>
-{% endcapture %}
-{% include "docs/example.html" html=html hide-code=true %}
-
-### Do
-
-- Explain what changed and why it matters.
-- Link to a related practical example if available.
-
-### Don't
-
-- Do not replace all practical examples with image-only examples.
-- Do not omit practical markup examples for core use cases.
-```
-
-- Do not move core documentation content (for example API details, states, accessibility rules,
-  migration notes) into `Examples`.
-- Keep core sections as normal documentation; `Examples` is an optional showcase section,
-  while visual preview blocks can be used across multiple sections.

.cursor/rules/html-elements.mdc

@@ -1,171 +0,0 @@
----
-description: Tabler Project HTML Elements Guidelines
-globs: ["**/*.html", "**/*.liquid", "**/*.md"]
-alwaysApply: true
----
-
-## HTML Elements Guidelines
-
-### 1. Icons
-
-When you need to use an icon, always use the Tabler icon include syntax:
-
-```html
-{% include "ui/icon.html" icon="ICON_NAME" %}
-```
-
-**Examples:**
-
-- `{% include "ui/icon.html" icon="home" %}`
-- `{% include "ui/icon.html" icon="building-community" %}`
-- `{% include "ui/icon.html" icon="map-pin" %}`
-
-### 2. Page Links
-
-When linking to other pages, always use the relative page syntax:
-
-```html
-href="{{ page | relative }}/url.html"
-```
-
-**Examples:**
-
-- `href="{{ page | relative }}/job-post.html"`
-- `href="{{ page | relative }}/job-listing.html"`
-- `href="{{ page | relative }}/marketing/index.html"`
-
-### 3. Static Generation
-
-All pages are statically generated to HTML using Eleventy (11ty). Keep this in mind when:
-
-- Writing frontmatter (must be static YAML, no Liquid templating)
-- Creating dynamic content (use Liquid templating in the body, not frontmatter)
-- Linking between pages (use relative paths)
-
-### 4. Additional Guidelines
-
-#### Frontmatter Rules
-
-- Frontmatter must be static YAML
-- Cannot use Liquid templating in frontmatter
-- Use static values for title, permalink, etc.
-
-#### Liquid Templating
-
-- Use Liquid templating only in the HTML body
-- Access data using `{{ variable }}` syntax
-- Use `{% for %}` loops for dynamic content
-- Use `{% if %}` conditions for conditional rendering
-
-#### File Structure
-
-- Pages go in `preview/pages/`
-- Includes go in `shared/includes/`
-- Data files go in `shared/data/`
-- Documentation goes in `docs/content/`
-
-#### CSS Classes
-
-- Use Bootstrap 5 classes
-- Use Tabler's custom CSS classes
-- Follow the pattern: `--#{$prefix}component-property`
-
-#### Accessibility
-
-- Include proper ARIA labels
-- Use semantic HTML elements
-- Ensure proper heading hierarchy
-- Add alt text for images
-
-### 5. Component Usage
-
-#### Cards
-
-- Use `card` class for main containers
-- Use `card-body` for content areas
-- Use `card-header` for card headers
-- Use `card-title` for card title
-
-#### Buttons
-
-- Use `btn` class for all buttons
-- Use `btn-primary` for primary actions
-- Use `btn` for secondary actions, don't use `btn-outline-secondary`
-- Use `btn-sm` for smaller buttons
-- Use `w-100` for full-width buttons
-
-#### Forms
-
-- Use `form-control` for input fields
-- Use `form-label` for labels
-- Use `form-check` for checkboxes/radio buttons
-- Use `form-select` for dropdowns
-
-#### Layout
-
-- Use Bootstrap grid system (`row`, `col-*`)
-- Use `container-xl` for main containers
-- Use `page-wrapper` for page structure
-- Use `page-body` for main content area
-
-#### Badges
-
-- Use `badge` class for badges
-- Don't use `badge-outline` for badges, use `badge` class instead
-- Don't use `badge-primary` for badges, use `badge` class instead
-- Don't change the text color of badges
-
-#### Markdown
-
-- Use `markdown` class for markdown content
-- Apply to containers that render markdown content
-- Example: `<div class="markdown">...</div>`
-
-#### Rest of the rules
-
-- Read the rest of the rules in the `docs/content/ui/` folder
-
-### 6. Data Integration
-
-#### Using JSON Data
-
-```liquid
-{% for item in items %}
-  <div>{{ item.name }}</div>
-{% endfor %}
-```
-
-#### Conditional Rendering
-
-```liquid
-{% if condition %}
-  <div>Content</div>
-{% endif %}
-```
-
-#### Including Components
-
-```liquid
-{% include "ui/button.html" color="primary" text="Click me" %}
-```
-
-### 7. Best Practices
-
-#### Performance
-
-- Minimize nested loops
-- Use `limit` filters when iterating large datasets
-- Optimize images for web use
-
-#### Code Organization
-
-- Keep components modular and reusable
-- Use consistent naming conventions
-- Comment complex logic
-- Group related functionality together
-
-#### Error Handling
-
-- Always check if data exists before using it
-- Provide fallback content for missing data
-- Use `{% if %}` guards for optional content

.cursor/rules/main.mdc

@@ -1,56 +0,0 @@
----
-description: Tabler Project Rules
-globs: 
-alwaysApply: true
----
-
-## Documentation Standards
-
-- Always write documentation in English (not Polish) for technical content
-- Use clear, descriptive headings with proper hierarchy (##, ###)
-- Include practical examples with code snippets
-- Add explanations for each component's purpose and usage
-- Use consistent formatting for code blocks and examples
-
-## CSS/SCSS Guidelines
-
-- Follow Tabler's CSS custom properties pattern: `--#{$prefix}component-property`
-- Use semantic class names that describe purpose, not appearance
-- Maintain consistent spacing and indentation in SCSS files
-- Group related styles together with clear comments
-- Use Bootstrap-compatible class naming conventions
-
-## Component Documentation Structure
-
-- Start with a brief description of the component's purpose
-- Show basic usage examples first
-- Include variations and modifiers
-- Add accessibility considerations where relevant
-- Provide code examples that are copy-paste ready
-
-## File Organization
-
-- Keep documentation files in `docs/content/ui/components/`
-- Use consistent naming: lowercase with hyphens
-- Include frontmatter with title, summary, and description
-- Link to Bootstrap documentation when relevant
-
-## Code Examples
-
-- Use Liquid templating syntax for dynamic examples
-- Include both HTML and rendered output
-- Show responsive behavior where applicable
-- Demonstrate proper accessibility attributes
-
-## Git Commit Messages
-
-- Use English for commit messages
-- Follow conventional commit format when possible
-- Be descriptive about what was changed and why
-
-## Project-Specific Conventions
-
-- Tabler uses Bootstrap 5 as a foundation
-- Custom components extend Bootstrap functionality
-- Documentation should be comprehensive but concise
-- Examples should be practical and immediately usable

.cursor/rules/pull-request.mdc

@@ -1,39 +0,0 @@
----
-description: Pull Request Title & Description Rules
-globs:
-alwaysApply: true
----
-
-## Pull request title
-
-- Write PR titles in **English**.
-- Start the title with a **capital letter**.
-- Use **present tense** and keep it concise (ideally <= 72 chars).
-- Avoid a trailing period.
-
-### Examples
-
-- `Improve markdown table overflow handling`
-- `Clarify contributing branch naming`
-- `Add onboarding stepper page`
-
-## Pull request description
-
-- Write PR descriptions in **English**.
-- Focus on **why** the change is needed and what user-visible effect it has.
-- Keep it skimmable: bullets, short paragraphs, clear headings.
-
-### Recommended template
-
-```md
-## Summary
-- <1–3 bullets describing the change and why>
-
-## Changes
-- <key implementation notes, non-obvious decisions>
-```
-
-### Notes
-
-- If you changed SCSS or any package behavior, add a **changeset** describing it (one sentence, with backticks for code elements).
-- If a PR is WIP, mark it as draft and prefix the title with `WIP:` only while it is not ready for review.

.github/workflows/calibreapp-image-actions.yml

@@ -8,6 +8,10 @@ on:
       - '**.png'
       - '**.webp'
 
+permissions:
+  contents: write
+  pull-requests: write
+
 jobs:
   build:
     # Only run on Pull Requests within the same repository, and not from forks.
@@ -23,4 +27,4 @@ jobs:
       - name: Compress Images
         uses: calibreapp/image-actions@main
         with:
-          githubToken: ${{ secrets.GITHUB_TOKEN }}
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.gitignore

@@ -40,14 +40,15 @@ packages-zip/
 .env
 sri.json
 
-preview-astro
-docs-astro
-
 # TypeScript
 *.tsbuildinfo
 .tsbuildinfo
 
+# Astro generated types
+.astro/
+
 # Test coverage
 coverage/
 __screenshots__/
+__pycache__/
 .claude/launch.json

docs/.build/copy-assets.mjs

@@ -0,0 +1,52 @@
+// Rebuild Astro's public directory from source and generated workspace assets.
+import { cpSync, existsSync, mkdirSync, rmSync } from 'node:fs';
+import { dirname, join } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const root = join(dirname(fileURLToPath(import.meta.url)), '..');
+const repo = join(root, '..');
+const publicDir = join(root, 'public');
+
+const copies = [
+	{
+		from: join(root, 'assets'),
+		to: publicDir,
+		packageName: '@tabler/docs',
+		requiredFile: join(root, 'assets', 'css', 'docs.css'),
+	},
+	{
+		from: join(repo, 'core', 'dist'),
+		to: join(publicDir, 'dist'),
+		packageName: '@tabler/core',
+		requiredFile: join(repo, 'core', 'dist', 'css', 'tabler.css'),
+	},
+	{
+		from: join(repo, 'preview', 'dist', 'preview'),
+		to: join(publicDir, 'preview'),
+		packageName: '@tabler/preview',
+		requiredFile: join(repo, 'preview', 'dist', 'preview', 'css', 'demo.css'),
+	},
+	{
+		from: join(repo, 'shared', 'static'),
+		to: join(publicDir, 'static'),
+		packageName: 'shared assets',
+		requiredFile: join(repo, 'shared', 'static', 'logo.svg'),
+	},
+];
+
+rmSync(publicDir, { recursive: true, force: true, maxRetries: 5, retryDelay: 100 });
+mkdirSync(publicDir, { recursive: true });
+
+for (const { from, to, packageName, requiredFile } of copies) {
+	if (!existsSync(from) || !existsSync(requiredFile)) {
+		throw new Error(`copy-assets: missing ${requiredFile} — build ${packageName} first`);
+	}
+
+	cpSync(from, to, {
+		recursive: true,
+		dereference: true,
+		filter: src => !src.includes('/.vscode') && !src.includes('\\.vscode'),
+	});
+}
+
+console.log('copy-assets: done');

docs/.build/vite.config.mts

@@ -1,20 +0,0 @@
-import path from 'node:path'
-import { fileURLToPath } from 'node:url'
-import { createViteConfig } from '../../.build/vite.config.helper'
-import getBanner from '../../shared/banner/index.mjs'
-
-const __dirname = path.dirname(fileURLToPath(import.meta.url))
-
-const entryPath = path.resolve(__dirname, '../js/docs')
-const entry = `${entryPath}.ts`
-
-export default createViteConfig({
-	entry: entry,
-	name: 'docs',
-	fileName: () => 'docs.js',
-	formats: ['es'],
-	outDir: path.resolve(__dirname, '../dist/js'),
-	banner: undefined,
-	minify: false
-})
-

docs/.gitignore

@@ -1 +1,26 @@
-.vercel
+# build output
+dist/
+
+public/
+
+# generated types
+.astro/
+
+# dependencies
+node_modules/
+
+# logs
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+pnpm-debug.log*
+
+# environment variables
+.env
+.env.production
+
+# macOS-specific files
+.DS_Store
+
+# jetbrains setting folder
+.idea/

docs/.vscode/extensions.json

@@ -0,0 +1,4 @@
+{
+  "recommendations": ["astro-build.astro-vscode"],
+  "unwantedRecommendations": []
+}

docs/.vscode/launch.json

@@ -0,0 +1,11 @@
+{
+  "version": "0.2.0",
+  "configurations": [
+    {
+      "command": "./node_modules/.bin/astro dev",
+      "name": "Development server",
+      "request": "launch",
+      "type": "node-terminal"
+    }
+  ]
+}

docs/CHANGELOG.md

@@ -1,46 +0,0 @@
-# Tabler Documentation Changelog
-
-## 1.4.0
-
-### Patch Changes
-
-- 6c38a48: Update Bootstrap to v5.3.7
-- 6c47b5f: Change `package.json` to `core/libs.json` as a source of libraries
-- 70a41e4: Replace a package list in `download.md` with a link to the 3rd-party libraries page
-- Updated dependencies [6c4dd36]
-- Updated dependencies [6fec73a]
-- Updated dependencies [9951fe9]
-- Updated dependencies [db6200a]
-- Updated dependencies [e96f055]
-- Updated dependencies [a200d30]
-- Updated dependencies [6c38a48]
-- Updated dependencies [2a12f72]
-- Updated dependencies [49ab9ea]
-- Updated dependencies [666a296]
-- Updated dependencies [cfd4cb6]
-  - @tabler/core@1.4.0
-
-## 1.3.0
-
-### Patch Changes
-
-- 8f70185: Improve Introduction, Base, Layout and Plugins sections in documentation
-- e546706: Fix input mask example in docs
-- 8850f61: Enhance pagination component with new styles
-- 8470c9b: Fix broken links to other docs section and tabler.io website; improve some labels.
-- 6a3513f: Fix links in Tabler Emails introduction, improve "How to contribute" and other small fixes
-- 278967b: Fix switch icon examples with filled icons in documentation
-- 38ea9aa: Use primary color for `::selection` inside `<code>` in docs
-- 5b3e201: Fix documentation: remove duplicated code examples; increase height of dropdown examples; fix some links
-- 7b72653: Fix ribbon component in the documentation
-- c42b104: Fix incorrect label text on form elements docs page
-- 895f943: Use tabs-package include to show webfont install steps
-- 665472c: Demonstrate sticky header table more clearly in docs
-- 7917f86: Replace non-existent Vimeo file and enhance the inline player documentation
-- 7fc1d5c: Exclude headings in the carousel and modal examples from ToC
-- 7773ff2: Exclude headings inside `.example` from the Table of Contents
-- 222ddd4: Change WYSIWYG title to uppercase
-- 9b15b94: Add missing `.steps-vertical` classes in docs
-- 5fa662b: Use color-input examples in documentation
-- 5619b2d: Fix `src` links to images in README and getting-started docs page
-- f8075f6: Add documentation for 3rd-party libraries and resources

docs/README.md

@@ -0,0 +1,46 @@
+# Astro Starter Kit: Basics
+
+```sh
+pnpm create astro@latest -- --template basics
+```
+
+> 🧑‍🚀 **Seasoned astronaut?** Delete this file. Have fun!
+
+## 🚀 Project Structure
+
+Inside of your Astro project, you'll see the following folders and files:
+
+```text
+/
+├── public/
+│   └── favicon.svg
+├── src
+│   ├── assets
+│   │   └── astro.svg
+│   ├── components
+│   │   └── Welcome.astro
+│   ├── layouts
+│   │   └── Layout.astro
+│   └── pages
+│       └── index.astro
+└── package.json
+```
+
+To learn more about the folder structure of an Astro project, refer to [our guide on project structure](https://docs.astro.build/en/basics/project-structure/).
+
+## 🧞 Commands
+
+All commands are run from the root of the project, from a terminal:
+
+| Command                   | Action                                           |
+| :------------------------ | :----------------------------------------------- |
+| `pnpm install`             | Installs dependencies                            |
+| `pnpm dev`             | Starts local dev server at `localhost:4321`      |
+| `pnpm build`           | Build your production site to `./dist/`          |
+| `pnpm preview`         | Preview your build locally, before deploying     |
+| `pnpm astro ...`       | Run CLI commands like `astro add`, `astro check` |
+| `pnpm astro -- --help` | Get help using the Astro CLI                     |
+
+## 👀 Want to learn more?
+
+Feel free to check [our documentation](https://docs.astro.build) or jump into our [Discord server](https://astro.build/chat).

docs/astro.config.mjs

@@ -0,0 +1,35 @@
+// @ts-check
+import { defineConfig } from 'astro/config'
+import mdx from '@astrojs/mdx'
+import { fileURLToPath } from 'node:url'
+
+// https://astro.build/config
+export default defineConfig({
+  site: 'https://docs.tabler.io',
+  // pages live at the package root (./pages) — content-first layout; all
+  // components/lib/data are shared (see the @shared alias)
+  srcDir: '.',
+  vite: {
+    // InlineScript.astro emits scripts inline at the component site —
+    // docs pages have no <PageScripts /> drain
+    define: {
+      'import.meta.env.INLINE_PAGE_SCRIPTS': 'true',
+    },
+    resolve: {
+      alias: {
+        '@data': fileURLToPath(new URL('../shared/data', import.meta.url)),
+        // Astro components/lib shared with preview-astro (single source of truth)
+        '@shared': fileURLToPath(new URL('../shared/astro', import.meta.url)),
+        // this package's pages dir — used by @shared/lib/docs-children's glob
+        '@pages': fileURLToPath(new URL('./pages', import.meta.url)),
+      },
+    },
+  },
+  integrations: [mdx()],
+  markdown: {
+    smartypants: false,
+    shikiConfig: {
+      theme: 'github-dark',
+    },
+  },
+})

docs/content/content.11tydata.mjs

@@ -1,6 +0,0 @@
-export default {
-	layout: 'docs/default',
-	permalink: function ({page}) {
-		return `${page.filePathStem.replace(/^\/content\//, '/').replace(/\/index$/, '') }/index.html`;
-	},
-};

docs/content/icons/index.md

@@ -1,16 +0,0 @@
----
-title: Tabler Icons
-summary: Tabler Icons is a powerful and versatile icon library that offers a huge collection of high quality icons suitable for a wide range of applications. With its clean and modern aesthetic, extensive customization options, and user-friendly website and plugins, Tabler Icons is an excellent resource for designers and developers looking to enhance their projects with high-quality icons.
-order: 2
-description: Over 5000 pixel-perfect icons for web design and development
----
-
-# Browse icons
-
-Tabler Icons is a comprehensive icon library that features {{ iconsCount }} high-quality icons.
-These icons are designed with a clean and modern aesthetic, making them suitable for a wide range of applications.
-
-To use Tabler Icons, you can visit their website at https://tabler-icons.io.
-From there, you can browse the full collection of icons by category or search for a specific icon using the search bar.
-
-Once you have found an icon you like, you can download it in various file formats, including SVG, PNG, and Icon Font.

docs/content/illustrations/introduction/preview.md

@@ -1,17 +0,0 @@
----
-title: Preview
-summary: "Tabler Illustrations offers 80 illustrations in two themes: light and dark. You can use them in your projects to enhance the visual appeal and convey messages effectively."
----
-
-Look at full list of illustrations below and see how they look. Find out more and purchase Tabler Illustrations at [our website]({{ site.homepage }}/illustrations).
-
-{% assign all-illustrations = illustrations | sort %}
-<div class="row g-2 gy-6">
-{% for illustration in all-illustrations %}
-<div class="col-6 col-md-4 col-lg-3 text-center">
-<img src="/static/illustrations/light/{{ illustration }}.png" alt="{{ illustration }}" class="hide-theme-dark" />
-<img src="/static/illustrations/dark/{{ illustration }}.png" alt="{{ illustration }}" class="hide-theme-light" />
-<code>{{ illustration }}</code>
-</div>
-{% endfor %}
-</div>