beem-slide build

npx beem-slide build

Bundles every deck under slides/ into dist/. There is no server component and no runtime to keep alive — the output is files, and any static host will serve them.

Note the invocation: the scaffold does not ship a build script, so npm run build has nothing to run. See Overview.

Flags

--help lists three more: --app-shell, --no-slide-browser and --no-slide-ui. Those exist for the hosted pipeline — the studio shell and one-click publishing — and while they work locally they are not a stable interface and can change when the pipeline does. For a trimmed public build, use the config instead; it is the supported route and it is checked into the repo where you can see it.

Output

dist/
├── index.html
├── assets/
│   └── …hashed js, css and deck assets…
└── …

Trimming what ships

A build for a client is not the same artefact as a build for internal review. The framework's own furniture — the deck index, the authoring chrome, the download button — is usually not something you want to hand over:

import type { BeemSlideConfig } from '@beem-slide/core';

const config: BeemSlideConfig = {
  build: {
    slides: ['q2-launch'],
    showSlideBrowser: false,
    showSlideUi: false,
    allowHtmlDownload: false,
    basePath: '/decks/q2',
  },
};

export default config;

build.slides and --deck do the same job; the config version is the one to reach for when the subset is a property of the project rather than of one command you happened to run.

Only build reads slides. dev always serves the whole folder, so narrowing what you publish never narrows what you can work on locally.

One deck named plus showSlideBrowser: false makes that deck the site: it renders at the root instead of the root being an index of one thing.

See Export for the rest of the build options, and for the PDF and PPTX routes out.