Feat: Creating vite-plugin.js for boboko/core

docs/modules.md

@@ -122,6 +122,63 @@ Docker Compose merges `volumes:` lists additively across `-f` files, so the over
 
 ---
 
+## Frontend Assets (JS/CSS)
+
+A module's JS (Stimulus controllers) and CSS ship as plain source files under `resources/js/` and `resources/css/` — **there is no separate npm package per module.** A module is never `npm install`ed; its frontend assets are read directly by the consuming app's own Vite build, straight out of `vendor/boboko/<module>`.
+
+This mirrors the PHP story above exactly: Composer already gives every environment one single, unconditional path — `vendor/boboko/<module>` — whether that resolves to a symlink into a sibling checkout (local path repo) or a real installed copy (tagged VCS release). A consumer's `vite.config.js` and JS entry point read from that same path, so there is nothing to toggle on the JS side — whatever Composer resolved is exactly what Vite sees, in both dev and prod, automatically.
+
+**Each module exposes one stable JS entry point** — `resources/js/index.js` — that re-exports whatever a consumer needs, e.g. `boboko-core`'s:
+
+```js
+// boboko-core/resources/js/index.js
+export { registerCheckout } from './checkout/index.js'
+```
+
+A consuming app imports from that one file only, never from a path reaching into a module's internal folder structure directly:
+
+```js
+// consumer app's resources/js/app.js
+import { registerCheckout } from "../../vendor/boboko/core/resources/js/index.js";
+registerCheckout(application);
+```
+
+```php
+{{-- consumer app's layout --}}
+@vite(['vendor/boboko/core/resources/css/checkout.css', 'resources/css/app.css', 'resources/js/app.js'])
+```
+
+This keeps a module's internal file layout free to change without breaking every consumer's entry point — the same reasoning as PSR-4 namespaces for PHP, just for JS imports.
+
+**A consuming app's `vite.config.js` needs one addition**, because `vendor/boboko/<module>` is a symlink in local path-repo dev (not a real directory Vite would otherwise watch through):
+
+```js
+export default defineConfig({
+    server: {
+        watch: {
+            // vendor/boboko/<module> is a symlink into ../boboko-<module> in
+            // local path-repo dev. Vite/chokidar don't follow symlinks for
+            // watched files by default, so edits to a module's source
+            // wouldn't otherwise trigger HMR. No-op against a real installed
+            // copy (tagged VCS release) in production.
+            followSymlinks: true,
+        },
+    },
+});
+```
+
+Bare imports inside a module's own JS (e.g. `leaflet`, `@hotwired/stimulus`) resolve against the **consumer's** `node_modules` via Node's normal upward resolution walk from `vendor/boboko/<module>/resources/js/...` — no extra config needed, as long as `vendor/boboko/<module>` sits inside the consumer's own directory tree (true for both the symlink and real-copy case). The consumer's Vite Docker service (if any) needs the same bind mount the PHP containers already get, landing at the equivalent path relative to its own working directory:
+
+```yaml
+# consumer app's docker-compose.core-dev.yml
+services:
+  vite:
+    volumes:
+      - ../boboko-core:/app/vendor/boboko/core   # match /app to the vite service's actual workdir
+```
+
+---
+
 ## Creating a New Module
 
 **1. Create the repository and `composer.json`:**