[project] Create Nuxt Module

[agritheory]

• Create installable Nuxt module (@stonecrop/nuxt)
• Integrate with Nuxt's routing system and use Stonecrop's router implementation for doctypes, throw error at build when conflicting routes exist
• Provide configuration API in nuxt.config.ts if required - reserve router and docbuilder keys for now
• Setup basic module structure with playground
• Runtime plugin for Stonecrop initialization
• Doctype auto-import should be enabled by globbing a @/doctype directory or specified "domains"- analogous to Frappe's modules/ "module def"
• Add schema-driven component auto-import - unused components should not be imported
• Add module option for docbuilder UI - this should be configurable as a module argument in nuxt.config.ts and could be sensitive to process.env for example
• Integrate event hooks from Workflow with Nuxt lifecycle hooks - requires [stonecrop] Fire events defined in schema from XState transitions #169
• AForm, ATable, any other custom components should be automatically registered

[agritheory]

Doctype auto-import should be enabled by globbing a @/doctype directory or specified "domains"- analogous to Frappe's modules/ "module def"

We will want to accommodate a scenario where there's for example an @doctypes/admin folder with user, role, etc doctypes and a page located at @pages/admin/index.vue that acts as a landing page for that admin domain.

[Alchez]

@agritheory I'm writing down a potential spec for the docbuilder based on our conversation in Slack. While we're going through the design, I think #204 can probably move ahead and be merged, and I can create a separate PR focused on the docbuilder.

---

Assuming the following docbuilder structure: base routes/pages -> component -> meta APIs, I think the most likely candidate to implement docbuilder is during the Vue application setup.

I think the essential steps to setup docbuilder would be the following:

• Register components (by default, Listview.vue and Builder.vue) to the Vue application (this could be expanded to allow custom components instead)
• Add router paths (by default, /builder/ and /builder/:id) to represent the docbuilder views (this could be expanded to allow custom router paths for the components instead)
• Register meta APIs to be pre-fetched using router navigation guards to de-couple them from the components (by default, no APIs are registered, but we could define a schema for expected APIs for our in-built components)

If this setup is correct, it could imply a few possible entry-points:

• In a pure Vue application, the docbuilder could be enabled during the Stonecrop plugin installation.
  • The plugin options for it (atleast initially) would simply be the APIs to be used for fetching the doctype list and their metadata. The routes and components would be implicitly setup inside the plugin; in a later iteration, the plugin would allow registering custom routes and components.
• In a Nuxt context, the docbuilder could be enabled during the Nuxt-Stonecrop module installation.
  • The module options (possibly) would expect the APIs to be resolve-able and register them as server handlers. Our module would then resolve those API paths and register them as a router navigation guard (via useFetch).
  • Custom components and paths would be expected to be automatically available in the Nuxt application, so maybe we wouldn't need to do anything here for those?

What do you think?

---