Documentation for larsasub v0.38.2. On an older version? Your release notes ship with the package (CHANGELOG.md).

Building the dashboard assets#

The twelve bundled dashboards ship as prebuilt JavaScript and CSS in dist/. This page covers publishing those assets into your application and, when you change the Vue sources, rebuilding them. Which dashboards exist and how to switch them on is on Dashboards.

• Publishing the built assets
• What is in dist/
• Rebuilding the assets
• Using the Vue sources in your own build
• Source layout
• Translations

Publishing the built assets#

The built assets are committed in dist/ and ship with the package, so your application needs no Node toolchain. larsasub:install copies them to public/vendor/larsasub on every run, overwriting the previous copy:

php artisan larsasub:install

To publish only the assets, after an upgrade for instance:

php artisan vendor:publish --tag=larsasub-assets --force

Always pass --force. The assets are build output that must match the installed package version: a stale bundle reading a newer payload is a broken dashboard, not a customisation. Restyle the dashboards through configuration instead — see Theming.

What is in dist/#

One UMD bundle per dashboard page, one stylesheet and the Vue runtime. The tenant invoices dashboard reuses the customer invoices bundle, so twelve dashboards come from eleven bundles.

Each page's Blade view loads larsasub.css, then vue.global.prod.js, then its own bundle, all from public/vendor/larsasub. The bundles treat Vue as an external global (Vue) and carry their own component styles inline, so nothing is fetched from a CDN and nothing goes through your asset pipeline. Each URL carries the published file's modification time (?v=…), so a browser fetches the files again after you republish them.

Rebuilding the assets#

You only need this when you change the sources under resources/js or resources/css. You need Node.js 24 (the version the package's own build check uses) and npm. From the package root:

npm ci
npm run build

npm run build runs one Vite build per dashboard bundle (BUILD_TARGET=<name> vite build, configured in vite.config.js), then the Tailwind CLI for dist/larsasub.css, then copies the Vue runtime from node_modules. You can rebuild a single bundle with its own script:

build:subscriptions empties dist/ before it builds. Run it on its own and every other bundle is gone until you run the full npm run build.

Then publish the result into your application as above. The package's own CI rebuilds dist/ from source and fails when the committed files differ from a fresh build, so a source change in the package always comes with its rebuilt dist/.

Using the Vue sources in your own build#

The default is the standalone mode above: the package serves complete pages from the prebuilt bundles. If you would rather mount the components inside your own Vue application, publish their sources:

php artisan larsasub:install --vue-components
# or
php artisan vendor:publish --tag=larsasub-vue-components

This copies the components to resources/vendor/larsasub/js/components in your application, together with the modules they import by relative path (js/utils, js/types, js/composables) and the frontend translations (lang/*/frontend.json), laid out as in the package so every import resolves. Import the components from there. A later install never overwrites them: once published, they are your files.

The components are written with <script setup lang="ts">, so your build needs @vitejs/plugin-vue and TypeScript support.

Their classes (bg-background, text-primary, ...) come from the design tokens in the package stylesheet, which the tag publishes too, as resources/vendor/larsasub/css/larsasub.css. Two ways to style them:

• Link the compiled stylesheet, as the bundled dashboards do: publish larsasub-assets and load vendor/larsasub/larsasub.css. No build step, but it only holds the classes the package's own components use, and it carries Tailwind's base styles for the whole page.
• Build from the published source with Tailwind CSS 4: it is a Tailwind entry (@import 'tailwindcss'), and its @source glob scans the components published beside it, so classes you add to them are generated too. Build it as an entry of its own: it brings Tailwind's base styles, so @import it into a stylesheet that already imports tailwindcss and you get them twice.

Either way, override a token (--primary, --background, ...) in a stylesheet loaded after it to follow your own theme.

Source layout#

resources/
├── css/larsasub.css                  # Tailwind entry for dist/larsasub.css
├── lang/{en,nl}/frontend.json        # Dashboard texts, bundled at build time
└── js/
    ├── standalone-*-app.js           # One entry point per bundle
    ├── createStandaloneApp.js        # Shared bootstrap: reads window.LarsaSub, mounts the page
    ├── layout/StandaloneLayout.vue   # Page chrome: header, title, navigation
    ├── components/                   # Dashboards (My*, Tenant*) and their dialogs
    ├── composables/useNotification.ts
    ├── types/index.ts
    └── utils/                        # api.ts, translations.ts, shared helpers

Each entry point imports one page component (for example MySubscriptionDashboard.vue or TenantChargesDashboard.vue) and hands it to createStandaloneApp(), which reads the payload the Blade view put on window.LarsaSub, wraps the page in StandaloneLayout and mounts it on #larsasub-app.

Translations#

The dashboard texts live in resources/lang/en/frontend.json and resources/lang/nl/frontend.json, and are compiled into the bundles: a change to them needs a rebuild, and a published translation override does not reach them. Which language a page renders in comes from the locale in the page payload; an unknown locale falls back to English. See Multilingual plan content for what that means for a multilingual install.

In standalone mode createStandaloneApp() passes the texts to the page as a translations prop. A component mounted in your own application without that prop loads the same bundled files itself.