Hi everyone — we've been building Vikreya (https://vikreya.com) and we're opening it up publicly. It started as "why do I need a coupon app, a marketplace app, and a local-services app separately" and turned into one place for:

• Smart Deals — AI-powered search that surfaces real shopping deals
• Trades — buy/sell marketplace, free to list, no fees to browse
• Services — post a job, get quotes from local pros
• Rewards — earn points/cashback across all of it

It's still early and I'm sure there's rough edges — genuinely want to hear what's broken or missing.

Best regards

Self-promo disclosure: I maintain poveste, a component playground continuing histoire. Two Svelte 5 fixes worth sharing — both failed silently, and both apply to anyone wrapping or re-mounting user components.

1. $capture_state / $inject_state are gone

A playground mounts your story twice — once for the controls panel, once for the preview. histoire bridged those two instances with $capture_state / $inject_state. They were dev-only compiler internals, and Svelte 5 removed them.

Without the bridge, a plain let exists twice. The checkbox writes to one copy; your component renders the other. The control moves, nothing happens, no warning.

Fix: stop reading state out of components and own it instead.

<script>
  const initState = () => ({ disabled: false })
</script>

<Hst.Story {initState}>
  {#snippet children({ state })}
    <MyButton disabled={state.disabled} />
  {/snippet}
  {#snippet controls({ state })}
    <Hst.Checkbox bind:value={state.disabled} title="Disabled" />
  {/snippet}
</Hst.Story>

One object, both snippets. It also survives crossing into the preview iframe, which the old approach never could.

2. Spreading a bound prop drops its setter

Svelte 5 passes bound props as getter/setter pairs. Spread them onto a wrapper:

<Inner {...props} />

...and the spread invokes the getter, handing the child a plain value. The setter is gone, so bind: silently degrades to one-way. Forward the prop explicitly instead of spreading it.

---

Since the first failure was invisible, a story with controls but no initState now logs an error naming itself. Happy to answer migration questions.

Small project I’ve been chipping at: an editor for an animated SVG avatar. You pick a shape, a colour and an expression, line up animation states on a timeline, then export the result as SVG, PNG, GIF or MP4. Runs fully in the browser, no backend, no account.

The part I’d actually like feedback on is the split. The animation core has no Vue import and no clock: it’s one pure function of time, so a frame depends only on its timestamp. The component drives it from requestAnimationFrame, but the tests run with no DOM at all, and a “frozen” prop renders one exact frame without starting a loop, which is how the thumbnail grid works without spawning one rAF loop per tile.

Two things I’d do the same way again:

• defineModel for the playback cursor, so the timeline and the player stay in sync without an event bus
• keeping the MP4 encoder behind a dynamic import. I broke this once: a two-line helper imported from the wrong module dragged 43 kB gzip back onto first load, and Vite’s INEFFECTIVE_DYNAMIC_IMPORT warning was the only sign anything was wrong.

Still a work in progress, so tell me what’s confusing, especially in the editor.

https://github.com/jeremy-prt/bloub

Hi all,

I've been working on yapyak, an open-source i18n compiler that runs as a Vite plugin. There are adapters for a few frameworks, but SvelteKit is the one I use myself.

The idea is that the source string is the key:

<script lang="ts">
  import { t } from 'yapyak';
</script>

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

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). 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 97px 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.

In the SvelteKit SSR adapter, locale state is scoped per request on the server and uses Svelte's reactivity on the client. Switching locale is synchronous, since the translations a module uses get compiled into it. A fixed-locale build can compile t() away entirely and leave just the translated string.

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. There's no follow-up post where I get to the pricing.

MIT licensed, and still pretty early.

yapyak.dev

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

Valux, remember the name.

I couldn’t find a Vue web component library that combines AppKit-style controls with Tahoe-style Liquid Glass, so I started building MacVue

It currently includes 19 components based on AppKit metrics and states, with five control sizes, light and dark appearances, accent colors, and opt-in Liquid Glass. The refraction is implemented with SVG displacement filters inside components such as Switch and Slider, with fallbacks where it isn’t supported.

It’s still pre-1.0, so APIs may change. I’m deciding what to prioritize next: menus and overlays, or window, toolbar, and sidebar components.

Demo and docs: https://macvue.dev
GitHub: https://github.com/antonreshetov/macvue

I'm a Nuxt dev and my clients almost always end up asking for a CMS. My default answer used to be Strapi, but it's a whole separate service: its own hosting, its own deploys, and the monthly cost for the client goes up fast for what is usually a handful of collections.

At some point I thought: Nuxt already ships a server (Nitro), surely someone has built a CMS that just runs inside it? To my surprise, no. So I built it.

How it works:

- You define content types in code (a `cms.config.ts` file): collections, singles, relations, blocks, translatable fields. Schema, migrations and TypeScript types are generated from it.
- Editors get an admin panel at `/cms` with drafts, validation and a media library.
- You query content through a read-only GraphQL API, typed end to end with gql.tada.
- SQLite by default (zero setup), one config line to switch to Postgres or Turso.
- Media on any S3-compatible storage, or a local mode that just reads from your `public/` folder.

You deploy one thing: your Nuxt app. No second service, nothing extra to pay for.

I tried to cover Strapi's core features, so for most projects (I'd say 90% of my client work) switching is painless. It's still a beta though, and some corners are rough: auth is currently a single admin whose credentials live in env variables (I know, I know), multi-user and RBAC are on the roadmap. But I think it can already be genuinely useful.

It's MIT licensed: https://github.com/xleddyl/nuxt-cms

Feedback and issues very welcome!

I got tired of switching between Figma and my Nuxt app just to try out small UI changes, so I built Airship.

It wraps your dev server and adds a Figma-like canvas to your running app. Select an element, describe the change, and Claude Code applies it directly to your source.

You get streaming diffs, inline undo, and desktop/mobile frames so you can see changes across screens as you iterate.

It runs as a lightweight proxy with no plugins or build changes.

It uses your existing Claude Code subscription. Codex and OpenCode are supported too.

Fully open source and MIT licensed.

Fork it, star it, and make it your own :)

My test suite was fully green (261 tests) while a core feature was flat-out broken in a real Nuxt app. It came down to three separate Vue 3 behaviours, and none of them were exotic. And all three are the kind of thing that passes review, passes CI, and quietly does nothing.

1. onUnmounted + template refs: cleanup that never ran, not once

This looks fine and is a silent no-op:

const el = ref(null)

onMounted(() => {
  el.value.addEventListener('keydown', onKeydown)
})

onUnmounted(() => {
  el.value?.removeEventListener('keydown', onKeydown)  // el.value is null here
})

Vue resets template refs to null before onUnmounted runs. So el.value?. short-circuits, removeEventListener is never called, and every instance leaks its listener onto a detached element.

The optional chaining is what makes it invisible. I mean no error, no warning, nothing to notice. In my case this had been broken since the day it was written, and it affected the shortcuts that had "worked fine" for weeks, not just the new ones.

Fix: capture the element in the onMounted closure and register the teardown there.

onMounted(() => {
  const node = el.value
  node.addEventListener('keydown', onKeydown)
  onUnmounted(() => node.removeEventListener('keydown', onKeydown))
})

2. defineModel doesn't apply a local set when the parent binds v-model

This is the one that cost me the most time. When the parent binds v-model, defineModel only emits — it does not update the local value. The new value comes back through the prop on the next tick.

That deferred round-trip broke my document sync. I had a watcher distinguishing "the user edited something in here" from "the host app replaced the whole document," using a flag set during internal writes. But the write and the echo are not in the same tick: by the time the value arrived back through the prop, the flag had already been cleared, so every single internal commit was classified as an external document replacement — which reset undo history. Undo was permanently dead in the real app, and every test was green.

The reason CI never caught it was that no test bound a live parent v-model listener. Without a parent actually listening, defineModel falls back to updating locally, the deferred path never runs, and the bug does not exist in the test environment.

Two things fixed it. First, stop using a flag and compare object identity of the last document written out because identity survives across ticks, a boolean doesn't. Second, and this cost me a second round of red tests: use toRaw when comparing. A deep ref hands your watcher a proxy, not the object you stored, so identity comparison fails until you unwrap it.

Then I added an end-to-end test that mounts the component with a real v-model round-trip. The fact that it fails with the old code is exactly why I trust it.

3. structuredClone throws on Vue proxies, but only from the second mutation on

The intermittency is what makes this one nasty.

// commit
history.push({ ...data.value })   // members read through the reactive proxy

Spreading a reactive object gives you a plain top-level object whose members are still proxy-wrapped. First mutation clones fine. From the second one on, structuredClone hits a proxy member and throws.

toRaw only unwraps one level, so calling it on the result doesn't save you. Unwrap before the spread:

history.push({ ...toRaw(data.value) })

---

All three only broke in situations my tests didn’t cover: a real unmount, a real parent listener, and a second mutation. The tests were green, but I just wasn’t testing the right thing.

These came out of building Gissen, an open-source headless visual editor for Vue 3.