Declare the module's JS dependencies in a package.json

[HafizMMoaz]

Part of zerp-pk/zerp#56, which asks that each module own its frontend build.

This lands the part that is achievable today: declaring the module's JS dependencies, the issue's third complaint ("Module JS deps are invisible and unversioned at the package level").

The problem it fixes

The package shipped only a composer.json. Every JS library this module's own code imports was declared solely in the host app's package.json. Nothing recorded that this module needs them, so dropping one from the host would break this module silently, and there was no way to see a module's frontend surface without grepping its source.

package.json now lists what the frontend actually imports, pinned to the versions the host already resolves.

They are peerDependencies, not dependencies: the host compiles this module's JS and resolves it from the host's node_modules. The module must not install its own copy. A second copy of React or the Inertia client would not merely duplicate bytes, it would break the app, since a second React instance means a second context tree.

No build script, deliberately

The issue also asks for a build script and compiled assets shipped with the package. That is not possible as the code stands, and shipping a build script that cannot produce a usable bundle would be worse than shipping none.

A module cannot compile standalone. Its frontend imports the host app's UI kit, layouts, hooks and contexts through the @/ alias, which tsconfig.json resolves to the host's ./resources/js/*. Across all 32 modules that is 5,528 imports into 64 distinct host paths, led by:

579  @/components/ui/button        246  @/layouts/authenticated-layout
459  @/components/ui/dialog        170  @/components/no-records-found
363  @/components/ui/label         149  @/components/ui/confirmation-dialog
339  @/components/ui/input         130  @/hooks/useDeleteHandler
336  @/utils/helpers                87  @/types/common

Compiling that into a self-contained dist/ would mean bundling a private copy of the host's 59-component UI kit, its layouts and its contexts. That breaks rather than duplicates: authenticated-layout, brand-context, i18n and Inertia all assume a single shared React instance and provider tree.

Getting to a real per-module build needs one of two architectural changes, neither of which belongs in this PR:

1. Extract the host's components/ui, layouts, hooks and utils into a versioned package both host and modules depend on.
2. Compile modules with @/* as externals, resolved at runtime through a host-side registry (Module Federation or an import map).

Full analysis is on zerp-pk/zerp#56. This PR is a prerequisite for either path: you cannot version a module's frontend without first knowing what it depends on.