feat: add deskcrew module

[webmilmind1]

Adds @deskcrew/nuxt, a module that puts a support widget (live chat, answers drawn from the site's own help articles, and a help center) on every page of a Nuxt app.

• npm: https://www.npmjs.com/package/@deskcrew/nuxt (v1.0.2, MIT)
• Repo: https://github.com/webmilmind1/nuxt-deskcrew
• Docs: https://deskcrew.io/integrations/nuxt

The module appends one script tag to app.head.script. The widget renders in a Shadow DOM, so it cannot inherit or leak app CSS. Works with Nuxt 3 in both SSR and static (nuxi generate) modes. A missing or malformed key produces a build-time warning and adds nothing, so the app still builds.

Filed under AI since the widget's answers are generated from the site's own knowledge base.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 703b34f0-2f67-4fe0-a4b8-5c416ec19be1

📥 Commits

Reviewing files that changed from the base of the PR and between 1e91933 and 1843dc6.

📒 Files selected for processing (1)

• modules/deskcrew.yml

🚧 Files skipped from review as they are similar to previous changes (1)

• modules/deskcrew.yml

---

📝 Walkthrough

Walkthrough

Adds a deskcrew Nuxt module registry manifest with descriptive metadata, links, classification, maintainer details, Nuxt 3 compatibility, and an empty requirements map. Updates pinia-orm to require Nuxt 3.14.0 or newer.

Estimated code review effort: 1 (Trivial) | ~2 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly matches the main change: adding the DeskCrew module.
Description check	✅ Passed	The description accurately describes the new DeskCrew module and its Nuxt support behavior.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[danielroe]

looking at this, I think it should probably use https://scripts.nuxt.com - and/or maybe this could just be replaced by adding deskcrew to the nuxt/scripts registry? wdyt @harlan-zw?

[webmilmind1]

@danielroe agreed, this is a better fit than a standalone module. DeskCrew is one third-party script tag, and everything a module adds on top (deferred loading past hydration, a typed API, dev-time validation) is what a registry entry already gives you.

I've gone through how an entry is actually built: the def() in packages/script/src/registry.ts, the valibot schema in runtime/registry/schemas.ts, the composable in runtime/registry/deskcrew.ts, the ScriptRegistry and BuiltInRegistryScriptKey additions in runtime/types.ts, and the docs page. Crisp and Intercom are the obvious references, and a facade defaulting to trigger: 'click' fits since we render our own launcher.

@harlan-zw two things before I write any of it.

First, config shape. DeskCrew takes its config from data attributes rather than a JS init call:

<script src="https://deskcrew.io/desk.js" data-key="pub_xxx" data-board="tenant-slug"></script>

Crisp and Intercom both configure through pre-load globals in clientInit, while Umami and Fathom pass config as data-* via scriptInput. My instinct is to follow the Umami shape. Is that acceptable for a support-category entry, or would you rather we expose a programmatic window.DeskCrew.init({ key, board }) so it configures via clientInit like the other two? Happy to add one, it's a small change on our side.

Related, and worth flagging rather than you finding it: window.DeskCrew is currently a queue-style stub that gets replaced with the real object once the widget boots, so a reference captured by use() before load would go stale. I'll make that identity stable before we ship anything that depends on it.

Second, bundling. Our script derives its API origin from its own src, so self-hosting it would point the widget at the customer's domain and break every call. I'd ship the entry with no bundle and no proxy to start (same position as Crisp), unless you'd prefer we add an explicit origin option so bundling works properly.

I saw nuxt/scripts#177 is the route for new registry scripts, and that the bar is deliberately high. Would you like a request posted there first, or is it fine to open the PR off the back of this thread? Either way I'm happy to do the work: entry, docs page, playground page and a public test id for generate-sizes.

[harlan-zw]

Please open a PR if you'd like :)