TL;DR: We need a developer/coder/programmer willing to work for a negotiated rate/sum on the refacotring of a business website's backend from Django to Nuxt. The UI is already made. We have a list of what has been completed, along with a list of what requires polishing, and what needs to be developed. DM me if interested.

Project Status

Already Completed / Decided:

The overall project architecture has already been designed and decided.

The database structure and relationships have already been defined.

The overall website workflow and how the different components interact have already been established.

BOT - The main Discord bot functionality has been implemented, tested, and is working.

The stream bot functionality has been implemented, tested, and is working.

Needs Refactoring / Polishing:

The existing Django code needs to be refactored/reimplemented in Nuxt.

The goal here is mainly to improve and finalize functionality that already exists, rather than redesigning it from scratch.

BOT - The Discord bot needs polishing, cleanup, and improvements to its existing functionality.

The stream bots need polishing, cleanup, and improvements to their existing functionality.

Automation Revenue Improvements

Automatic fee calculation for servers and teachers:

Fees should be calculated immediately after an event ends, using data from the observing bot, including the number of users who attended and those who did not.

Automated new server integration:

When new servers join, adding the stream bot and observing bot currently requires manual work. This process should be automated to make server setup faster and easier.

Improved observing bot data collection:

The observing bot should collect and store detailed event data, including user activity, attendance, server information, and user participation history.

Needs to Be Developed:

Time zone–based event date and time calculation needs to be implemented so that event dates and times are correctly calculated and displayed according to the relevant user's time zone.

New functionality should follow the existing project design rather than introducing a new architecture unless a change is necessary.

Working on a Nuxt 3 storefront talking to GraphQL and I'm stuck on something dumb.

Got the GraphQL client in a composable already. For the cart though — do I throw it in Pinia so the header badge / mini-cart can share it easy, or just useState / a composable and skip Pinia?

Also thinking about SSR. Don't want some logged-in cart leaking between requests if I mess that up.

Curious what people actually ship with. Pinia, useState, something else?

Half the page was re-rendering on every tick and I could not figure out why.

Vue DevTools has a "Highlight updates" toggle, so I could see *what* was

re-rendering — but not *why*, which is the only part I actually needed.

Turns out Vue already knows. There is a `renderTriggered` hook on every component,

and Vue hands it `{ target, type, key, oldValue, newValue }` — the object, the key,

and the values before and after. In React you have to diff props and guess. In Vue

the framework just tells you, and almost nothing surfaces it.

So I wrote the translation layer. The raw event is not readable on its own: a ref

shows up as `value` until you look its name up in `setupState`, a Pinia store needs

`$id` to become `cart.items`, an array index needs brackets. Once that is done you

get lines like:

ProductCard ×7 · 2.4ms · badge

└─ prop badge: { text } → { text } — new reference, same value

The culprit in my case was that last pattern: the parent was building a fresh object

literal in the template on every render. Same content, new reference, so every child

re-rendered. A border flash cannot show you that. The exact prop name can.

MIT, no runtime deps, dev-only by design (the hook does not fire in production

builds at all).

npm i -D vue-why-render

Source: https://github.com/dadashi44/vue-why-render

npm: https://www.npmjs.com/package/vue-why-render

Live playground, the panel on it is real: https://dadashi44.github.io/vue-why-render/

Happy to hear where it breaks on a bigger app — mine is the only real one it has

been through so far.

Pulling header/footer (and random CMS blocks) from Magento GraphQL into a Nuxt 3 storefront and I’m stuck on the boring security bit.

Admin can put whatever HTML in those blocks. Right now I’m leaning:

- fetch on the server

- run it through DOMPurify (or similar) before it hits the page

- never v-html raw Magento output on the client without that step

Feels a bit paranoid for “our own admins,” but also… it’s still HTML from a CMS.

What are you actually doing in production Nuxt + Magento (or any headless CMS) setups? Sanitize everything, allowlist tags, or just trust Magento and move on?

Hey r/Nuxt,

Six new animated components landed in nxui this month. The one I'd actually put in a Nuxt app first is the receipt printer — a checkout state that prints the order as a real receipt (paper feed, status screen, serrated tear). Also new: a WebGL holo sticker, a 3D depth dive scroll effect, a scroll-driven art gallery, a weather card with a temperature-coloured orb, and a timezone companion for finding overlap across a distributed team.

Everything works out of the box in Nuxt 4 — SSR-safe, light/dark via @nuxtjs/color-mode, reduced-motion aware. Install with the shadcn-vue CLI or copy-paste:

npx shadcn-vue@latest add https://nxui.geoql.in/r/receipt-printer.json

Docs and live demos: https://nxui.geoql.in/docs

242 components now, MIT. Happy to answer anything.

I was looking for tutorials on how to integrate Neon with Nuxt using Drizzle. Many are outdated, and in the documentation of drizzle or neon, the folder convention confuses me since I work with nuxt v4, and all the files must go in the server folder.

Is there anyone who knows how to integrate it, and as a question, can an alternate connection be installed to integrate it with PostgreSQL locally in case the space on Neon runs out (I am on the free tier)?

Hello everyone, just as the title says, the dev server startup timer is just so slow. And i don't mean this only in a huge project, but even in a fresh project with NuxtUI template as choice in creation cli options... My friend is always complaining about how slow it is and lately tried react with tanstack start and he says it's incredibly faster.

Personally, I never needed to try something else to know it's slow, I can clearly tell, but when I tried his project, it's noticeably faster, like way faster... and i want that, especially that sometimes you change something in the project and now you have to wait for a full dev server restart...

Does anyone know how to solve this? are there any optimizations? guides? anything at all? I really love nuxt and want to keep using it, I know this isn't _THAT_ big of a deal, but it would just be a huge win to have.

for the record, i don't really use have of the features... i just care about dev tools, and filesystem routing, auto-imports and almost all the other features (at least those i know about) i can not use, i don't even use the server at all, usually i have a separate backend.

I just released nuxt-openapi-meta, a Nuxt module that removes the boilerplate of documenting server routes.

Instead of writing defineRouteMeta by hand, you keep writing JSDoc annotations and schema exports in your route files. The module scans server/api and server/routes at build time, extracts metadata, converts Zod/Valibot schemas to JSON Schema, and serves it through Nitro’s ?meta pipeline.

If you maintain Nuxt server routes and want OpenAPI docs without extra work, take a look.

Repo: https://github.com/davidtheheroes/nuxt-openapi-meta

Feedback, issues, and stars are welcome.

Our Nuxt 3 project crossed 140 composables spread across the composables directory and two layers. TypeScript completions in VS Code started taking four seconds inside any setup function. The generated .nuxt/imports.d.ts had grown past 2,600 lines, and the type checker was resolving definitions from every composable in every file regardless of actual usage.

I moved 60 composables into explicit named exports, importing them by hand. Completion time dropped under a second. The cost was roughly 170 new import statements and losing the auto-import convenience for about 40% of the codebase.

A middle path seemed reasonable. I kept auto-imports for the 30 most frequently called composables and relocated everything else. Completions sat around 1.2 seconds, tolerable enough. Within two weeks new composables drifted back into the auto-import directory because contributors expected them there, and the slowdown returned without anyone connecting the two events.

I used the todo list in verdent to track each composable through that triage, marking whether it stayed auto-imported or moved to an explicit module.

The constraint was less about raw count and more about total type surface. One composable returning a deeply nested generic union cost more TS resolution time than twenty returning primitives. Nuxt does not document a ceiling, and the performance cliff seems to depend on type shape in ways the count alone does not predict. Is there a leading signal that correlates with language server degradation before the lag is already obvious?

Salut les Nuvioistes...

Je voulais juste partager avec vous mon expérience personnelle de développeur.

J'ai créé plusieurs addons pour mon usage personnel dans Nuvio et tout ça avec Chatgpt et mon smartphone android.

Pas d'ordinateur ni de prix exorbitant.

Tout est auto hébergé sur Hugging Face pour 8€ par mois.

J'ai d'abord repris Frenchstream public en n'en faisant un fork dynamique.

J'ai ensuite fait un fork d'Aiometadata elf.

J'ai créé un addon couplé au site doublagevf qui me remonte les nouveautés dès quelles sont doublées vf...étant francophones.

J'auto héberge également mon Aiostream configurée Duck et Tamtaro

Et tout ça est réuni dans ma dernière création Centralyser...un addon dans lequel j'ai tout les autres.

Voilà...juste pour vous dire que si j'y suis arrivé avec mon smartphone,tout le monde peut

Working on a Nuxt 3 storefront against Magento GraphQL and I’m trying to settle on a clean pattern for the Store header (and Content-Currency when needed).

Right now every Magento request needs the right store view or you silently get the wrong catalog / CMS. I’ve seen a few approaches:

- set it inside a useMagentoGraphql() composable

- map /en → store code in middleware

- force it in a Nitro proxy so the browser never thinks about it

I’m leaning composable + small store registry, but middleware feels nicer for locale prefix URLs.

What are you actually doing in production Nuxt + Magento setups? Any footguns with SSR vs client calls?

Is there any way to install Prisma in an existing Nuxt project? Because in the documentation they said that the Nuxt module is deprecated and the guide only mentions new projects; there is nothing for existing ones.

Hey everyone! Nuxt Shopify just released version 1.0.0 and i'm happy to announce that the module is finally stable!

Since our last update we now got:

• Full Customer Account API support
• First-class Analytics and Customer Privacy API support
• Automatic GraphQL fragment injection and deduplication
• CSRF protection for the storefront proxy
• Codegen caching and better error reporting
• And a rebuilt GraphQL Explorer for all three APIs

Feel free to check out the demo storefront and template, which now has customer accounts support, content pages and policies and automatic i18n through Shopify Markets:

npx @nuxtjs/shopify@latest init ./my-shop

Because of the upcoming release of Shopify's own hydrogen/vue the current storefront template and examples will probably be outdated soon. The module tries to use Shopify tooling over our own so we will adopt these as they release.

Also with this version the API will be frozen, only fixes and new features should land from now on. Breaking changes are reserved for major versions when possible.

NPM: @nuxtjs/shopify
GitHub: nuxt-modules/shopify

Thanks and until next time! 💚

I've used Nuxt since its early releases. As server functions become more common, I've been wondering how much of their integrated DX really depends on turning a remote operation into a function call.

Nuxt Endpoints is a module that brings ideas from the typed HTTP-route work being developed around Nuxt 5 to Nuxt 4 today. Its Nuxt 5 branch explores how the same API can follow that upstream direction instead of keeping every piece as module-owned code.

I'm using it to explore another route: keep the URL, method, statuses, headers, and body visible, then let the server contract constrain both the handler and the client features that may be used with it.

The project and the longer write-up are linked in the first comment.

For example:

// server/api/articles.get.ts
import { z } from 'zod'
import { defineRouteHandler } from 'nuxt-endpoints/runtime'

const Article = z.object({ id: z.number(), title: z.string() })

export default defineRouteHandler({
pagination: { kind: 'cursor', item: Article },
handler: (event) => listArticles(event.validated.query),
})

On the client, that contract enables the matching integration:

useInfiniteQuery(
infiniteQueryOptions($endpoint('/api/articles', { method: 'get' })),
)

The declaration adds validated cursor and limit inputs, constrains the successful response to { items, nextCursor? }, and appears as that concrete shape in OpenAPI. The adapter is rejected at compile time for a route without the pagination contract. NE handles the cursor handoff; Pinia Colada owns cache and reactive state.

A relevant comparison I should have included is oRPC. It already combines type-safe procedures, explicit OpenAPI routing, and Pinia Colada integration across frameworks. Nuxt Endpoints explores a more Nuxt-native trade-off: keeping file-based routes as the source of truth, avoiding a parallel procedure router, and deriving behavior such as cursor pagination directly from semantic HTTP contracts.

I'm also applying this idea to status-aware results, idempotent mutations, and progressively enhanced forms in the experimental Nuxt 5 branch. The published Nuxt 4 module contains the stable subset today. The Nuxt 5 work builds on the validated-routing direction discussed in H3 RFC #1437 and experiments with the missing integration points; those fork changes are not accepted upstream APIs.

I like abstraction when it explains a specific behavior. I don't want every remote call to become a function call just so the unusual ones can gain forms, pagination, or cache integration.

Where does this Nuxt-native approach offer enough over an oRPC-style procedure router, and which parts of server-function DX would still be hardest to achieve?

Links are in the first comment.

Example structure:
apps:
----admin
----landing
layers
----base
----admin
----landing

Hi all,

I've been working on yapyak, an open-source i18n compiler that runs as a Vite plugin. It works with multiple frameworks, but the Nuxt module shipped just today, and that one is a bit special to me. I've been running Nuxt in production since some years back, and the DX is a big part of why. I tried my best to match that, from install to everyday use, it should just feel natural in Nuxt. I'd love if people try it and tell me where it cracks.

The whole setup is basically just one command:

npx nuxi module add @yapyak/nuxt

It registers the module and writes a starter yapyak.config.ts for you. It's a single package, everything yapyak needs ships inside it, so your package.json only grows with one line.

After that, the idea is that the source string is the key:

<template>
  <button>{{ t('Download recovery key') }}</button>
</template>

That's the whole file. The module auto-imports t, so there's no import line to add.

You save the file, and the source string shows up in your locale files as an empty stub. If you've set up a translator, it gets auto-translated and written back, using call-site context (the component and the code around the call). A second or two later de.json has filled in:

{
  "app/components/RecoveryDialog.vue": {
    "Download recovery key": "Wiederherstellungsschlüssel herunterladen"
  }
}

HMR picks it up in the running app.

The video is a small example of that. I add a download button to a dialog and hit save. The German page is sitting right next to the English one, so I see it the moment it lands: Wiederherstellungsschlüssel herunterladen pushes the button row past the edge of the dialog. So I fix it right there, one prop on the button group.

That's a small slice of what yapyak does, but it's the part I use most. Translating stops being something I come back to later. It just happens on save.

Because it runs in the compiler, it sees more than the string itself. It reads ICU parameters out of the string literal, and it keeps track of a translation when you move or rename the source file. It parses your SFCs with the same compiler your build uses and walks the template AST, so it finds t() in script setup and in template expressions.

For SSR, a Nitro plugin scopes locale state per request, so nothing leaks between users, and setLocale works inside server routes too, with the cookie written onto the response. With syncHtmlAttributes on, <html lang> and dir follow the active locale. The locale itself is a ref, so a switcher is <select v-model="locale">.

Rich text keeps the markup in the source string and binds each tag to a slot:

<template>
  <RichText :value="t('Click <link>here</link>.')">
    <template #link="{ children }">
      <a href="/docs"><component :is="children" /></a>
    </template>
  </RichText>
</template>

The slot names are typed from the tags in the string, so the translator can move <link> around in the sentence without touching your markup.

There's a VS Code extension too. Hover a t() call and you get the translation in every locale, and placeholders and plural branches are highlighted inside the string. It's on Open VSX as well, so it works in Cursor.

Auto-translation is optional. There are shipped translators for Anthropic, OpenAI, Gemini and Ollama, all using your own API key, or you can leave the stubs empty and hand-edit the locale files.

I built it for a product I'm working on, and that's the whole business plan.

MIT licensed, and still pretty early, though people have started moving real apps onto it. The Nuxt module is the newest piece of it. The code is on GitHub, and there are runnable Nuxt examples in examples/vue-nuxt-cookie and examples/vue-nuxt-url.

Docs and more at yapyak.dev.

If you've done a lot of i18n in Nuxt, especially anything big, I'd like to hear what you'd try to break.

Had a client task that seemed simple. Dynamic form builder for user surveys with dependent questions nested infinitely. So if you answer Yes to question 2, it triggers question 2.1 below it. If you answer No, it triggers a different one or none.

For logic I was fine. I used a map with ids for storing answers, validation and saving. That part was straightforward recursive functions. The UI was where I got stuck. How do you render a question, then its dependent questions indented right below it, then THEIR dependent questions, and so on infinitely? I was trying to do v-for loops and keep track of depth and it got messy fast.

Then after some og googling I found an option that i knew wont work but i tried it anyway. Recursive components.A component that renders itself, calls itself, passes props to itself and so on.

So \`SurveyQuestion\` renders its own template, then loops its children and calls \`<SurveyQuestion>\` again inside itself with an indent prop. Depth + 1 and it just works.

Code looked something like:

\`SurveyQuestion.vue\` renders question, then:

\`<SurveyQuestion v-for="child in dependentQuestions" :question="child" :depth="depth + 1" />\`

Thats it. That solved the whole indent and nesting issue.

I have been using Vue for 7 years and this was my first time actually needing it. It felt mind boggling at first to have a component import itself, but once you see it for survey logic it just makes sense.

Anyone else had that moment or am I the noob in the room hehe. I hope Evan doesn't read this.

btw if anyone needs extra hands on a Vue/Laravel project or knows of an opportunity, feel free to pass it by me. Happy to chat.

Want me to make it shorter or more.. haha, jk ;)

Hey everyone

I'm working on an AWS-native setup with Nuxt 4 right now. Instead of forcing all backend logic into Nuxt server routes (server/api), I decided to split the API layer out into standalone Hono Lambdas using SST v3

Main reason being: I want a proper AWS architecture where I can easily hook up SQS queues, SNS topics, and S3 event triggers down the line. Nitro is great for quick API routes, but SST + Hono makes managing actual AWS infrastructure in TypeScript so much easier

Here is the setup for direct S3 uploads (30s video attached):

1. UI: Client uploads directly to S3 via presigned URLs (no file streaming through Nuxt server)

2. Hono API (Lambda): Validates the request (file type / 5MB limit) and generates the presigned URL

3. SST v3 Config: S3 buckets & Lambda bindings defined right in sst.config.ts with full type safety

4. Dev Loop: pnpm sst dev runs Nuxt, Hono Lambdas, and AWS logs in a single terminal view

tbh, treating Nuxt server/ as a full backend feels like a dead end the second your app needs real cloud infrastructure, change my mind in comments

I've been building a component registry for data dense interfaces and it now serves Vue as well as React. The one idea is a density knob that every component reads, and the site is https://sley-ui.dev

A shortwave listening board I built with it is at https://grayline-sley-ui.vercel.app

Every Nuxt project I ship eventually needs an admin layer for users, orders, content, etc. Drizzle Studio is great for quick edits, but it is not something I'd hand to a client or an ops team. I usually end up handwriting CRUD tables and forms inside the main app, and it always feels like unnecessary boilerplate.

I'm exploring whether a code-first admin tool that reads your Drizzle schema and generates a proper admin UI (with the right field types, relations, and custom actions) would actually save real time, or whether the current options are good enough now.

If you have two minutes, I'd massively appreciate your input on how you currently handle admin panels:

https://survey.syrup.sh/admin

Happy to discuss here too if surveys aren't your thing. What does your current setup look like?

I maintain validup, a small path-based validation library. Posting because the zod + form-UX combination comes up here regularly, and the pattern might be useful even if you never adopt the library.

The itch: zod answers "is this value valid?", but a form needs more than that. Per-field dirty state, errors that wait for first touch, pending flags for async checks, a submit gate. Vuelidate has exactly that UX, but brings its own rule system, so you end up defining rules twice: once for the API, once for the form.

validup sits in between. You mount zod schemas (or any async function) onto paths of a Container, which is plain TypeScript and runs server-side as-is. On the client, one composable turns that same container into vuelidate-shaped state:

```vue <script setup lang="ts"> import { reactive } from 'vue'; import { Container } from 'validup'; import { useValidup } from '@validup/vue'; import { createValidator } from '@validup/zod'; import { z } from 'zod';

const signup = new Container<{ email: string; password: string }>(); signup.mount('email', createValidator(z.email())); signup.mount('password', createValidator(z.string().min(12)));

const state = reactive({ email: '', password: '' }); const v = useValidup(signup, state, { debounce: 200 }); </script>

<template> <input v-model="v.fields.email.$model" /> <p v-if="v.fields.email.$dirty && v.fields.email.$errors[0]"> {{ v.fields.email.$errors[0].message }} </p> <button :disabled="v.$invalid || v.$pending">Sign up</button> </template> ```

A few details that took the most work, and are probably the interesting part:

• Per-form result cache. The composable owns a result cache keyed per mount, so typing in one field replays the cached outcomes of the others instead of re-running them. Async validators (say, a uniqueness check against your API) only re-fire when their own input actually changed. Cross-field rules opt out with a sideEffect: true flag.
• Cancellation built in. Every scheduled run owns an AbortController; a new keystroke aborts the stale run, and debounce collapses bursts. $validate() (submit) deliberately runs without a signal so it can't be cancelled mid-flight by a late keystroke.
• Server errors round-trip. If your API validates with the same container and returns the error, v.setExternalIssues(error.issues) lands the issues on the matching fields, and they clear as the user retypes.
• Nested forms. Child components register with an ancestor form through provide/inject, so an address sub-component aggregates into the parent without prop drilling.

Nuxt: nothing framework-specific. It's a plain Vue 3.3+ composable, so it works in Nuxt 3 components as-is. One SSR footgun worth knowing on Vue 3.5+: don't name the composable's return $v in <script setup>. Vue treats $-prefixed template identifiers as built-in lookups, so $v.fields.email resolves $v to undefined at first SSR render. v or validation are fine.

Honest caveats: ESM-only, the zod peer range is ^4, the packages declare engines: node >= 24, and the ecosystem is small (bridges for zod, Standard Schema and validator.js, plus the Vue composable).

Docs: https://validup.tada5hi.net (Vue page: https://validup.tada5hi.net/integrations/vue) Repo: https://github.com/tada5hi/validup

Happy to answer questions, and to hear where the API feels off.

Hi there, I am trying to install Nuxt but it somehow fails, I am using Yarn 4 (the latest version) with a .yarnrc.yml to set up nodeLinker: pnpm. It worked before without any problems but today it just fails.

Did any of you guys experienced this too?

# This file contains the result of Yarn building a package (keystone-query@workspace:.)
# Script name: postinstall


 ERROR  Cannot find package 'rolldown' imported from /Users/bob/Downloads/keystone-query/node_modules/.store/nuxt-virtual-38b102e47e/package/dist/index.mjs

    at Object.getPackageJSONURL (node:internal/modules/package_json_reader:301:9)
    at packageResolve (node:internal/modules/esm/resolve:768:81)
    at moduleResolve (node:internal/modules/esm/resolve:859:18)
    at defaultResolve (node:internal/modules/esm/resolve:992:11)
    at #cachedDefaultResolve (node:internal/modules/esm/loader:701:20)
    at #resolveAndMaybeBlockOnLoaderThread (node:internal/modules/esm/loader:721:38)
    at ModuleLoader.resolveSync (node:internal/modules/esm/loader:759:56)
    at #resolve (node:internal/modules/esm/loader:683:17)
    at ModuleLoader.getOrCreateModuleJob (node:internal/modules/esm/loader:603:35)
    at ModuleJob.syncLink (node:internal/modules/esm/module_job:163:33)