virastack 1.0.1 → 1.0.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "virastack",
-  "version": "1.0.1",
+  "version": "1.0.3",
   "description": "Scaffold new projects and add tools from the ViraStack ecosystem with a single command.",
   "author": {
     "name": "Ömer Gülçiçek (ViraStack)",
@@ -33,6 +33,12 @@
     "templates-i18n",
     "!src/**/*.test.js"
   ],
+  "scripts": {
+    "prepublishOnly": "find templates templates-i18n -type d \\( -name 'node_modules' -o -name '.next' -o -name 'dist' -o -name '.vinxi' -o -name '.output' -o -name '.turbo' \\) -prune -exec rm -rf '{}' +",
+    "start": "node ./bin/virastack.js",
+    "test": "vitest run",
+    "test:watch": "vitest"
+  },
   "keywords": [
     "virastack",
     "start",
@@ -53,10 +59,5 @@
   },
   "devDependencies": {
     "vitest": "^3.2.7"
-  },
-  "scripts": {
-    "start": "node ./bin/virastack.js",
-    "test": "vitest run",
-    "test:watch": "vitest"
   }
-}
+}

package/templates/nextjs/src/proxy.ts

@@ -1,6 +1,6 @@
 import type { NextRequest } from "next/server";
 import { NextResponse } from "next/server";
 
-export function proxy(_request: NextRequest) {
+export default function proxy(_request: NextRequest) {
   return NextResponse.next();
 }

package/templates-i18n/nextjs/src/app/[locale]/layout.tsx

@@ -24,6 +24,10 @@ const inter = Inter({
 
 export const metadata: Metadata = defaultMetadata;
 
+export function generateStaticParams() {
+  return routing.locales.map((locale) => ({ locale }));
+}
+
 export default async function RootLayout({
   children,
   params,

package/templates-i18n/nextjs/src/i18n/routing.ts

@@ -5,7 +5,6 @@ export const routing = defineRouting({
   locales: ["en", "tr"],
   defaultLocale: "en",
   localePrefix: "as-needed",
-  localeDetection: false,
 });
 
 export const { Link, redirect, usePathname, useRouter, getPathname } = createNavigation(routing);

package/templates-i18n/nextjs/src/proxy.ts

@@ -6,7 +6,7 @@ import { routing } from "./i18n/routing";
 
 const handleI18nRouting = createMiddleware(routing);
 
-export function proxy(request: NextRequest) {
+export default async function proxy(request: NextRequest) {
   return handleI18nRouting(request);
 }
 

package/templates-i18n/tanstack/project.inlang/README.md

@@ -1,157 +0,0 @@
-## What is this folder?
-
-This is an [unpacked (git-friendly)](https://inlang.com/docs/unpacked-project) inlang project.
-
-## At a glance
-
-Purpose:
-
-- This folder is the Git-friendly representation of an `.inlang` project.
-- The canonical `.inlang` format is a single binary file; this directory is the unpacked version for Git.
-- This folder stores project configuration and plugin cache data.
-- Translation files live outside this folder and are referenced from `settings.json`.
-
-Safe to edit:
-
-- `settings.json`
-
-Do not edit:
-
-- `cache/`
-- `.gitignore`
-
-Key files:
-
-- `settings.json` — locales, plugins, file patterns
-- `cache/` — plugin caches (safe to delete)
-- `.gitignore` — generated
-- `README.md` — generated, explains this folder
-- `.meta.json` — generated SDK metadata
-
-```
-*.inlang/
-├── settings.json    # Locales, plugins, and file patterns; kept in Git
-├── .gitignore       # Ignores everything except settings.json
-├── README.md        # Generated, explains this folder
-├── .meta.json       # Generated SDK metadata
-└── cache/           # Plugin caches, usually cache/plugins/
-```
-
-Translation files (like `messages/en.json`) live **outside** this folder and are referenced via plugins in `settings.json`.
-
-## What is inlang?
-
-[Inlang](https://inlang.com) is an open project file format for localization. An `.inlang` project is canonically a single binary file: a SQLite database with version control via [lix](https://lix.dev). Like `.sqlite` for relational data, `.inlang` packages localization data into one file that tools can share.
-
-For Git repositories, that binary file can be unpacked into a directory of plain files. The packed file is the canonical format; this directory is the Git-friendly representation.
-
-Use inlang when multiple tools, teams, automations, or agents need to use the same localization data. The `@inlang/sdk` is the reference implementation for reading and writing `.inlang` projects.
-
-`.inlang` is the canonical project format. Plugins import and export external translation files for compatibility with existing runtimes and workflows. Messages, variants, and locale data live in the `.inlang` database; translation files such as `messages/en.json` live outside this folder and are connected through plugins. Version control via lix adds file-level history, merging, and change proposals to `.inlang` projects.
-
-It provides:
-
-- **CRUD API** — Read and write translations programmatically via SQL
-- **Plugin system** — Import/export external translation files (JSON, XLIFF, etc.)
-- **Version control** — Version control via [lix](https://lix.dev)
-
-Core data model:
-
-- **Bundle** — one translatable unit across locales
-- **Message** — locale-specific translation for a bundle
-- **Variant** — text pattern plus selector matches
-
-```
-┌──────────┐        ┌───────────┐         ┌────────────┐
-│ i18n lib │        │Translation│         │   CI/CD    │
-│          │        │   Tool    │         │ Automation │
-└────┬─────┘        └─────┬─────┘         └─────┬──────┘
-     │                    │                     │
-     └─────────┐          │          ┌──────────┘
-               ▼          ▼          ▼
-           ┌──────────────────────────────────┐
-           │          *.inlang file           │
-           └──────────────────────────────────┘
-```
-
-## Quick start
-
-```bash
-npm install @inlang/sdk
-```
-
-```ts
-import fs from "node:fs";
-
-import { loadProjectFromDirectory, saveProjectToDirectory } from "@inlang/sdk";
-
-const project = await loadProjectFromDirectory({
-  path: "./project.inlang",
-  fs,
-});
-// Query messages with the SDK.
-const messages = await project.db.selectFrom("message").selectAll().execute();
-
-// Use project.db to update messages.
-await saveProjectToDirectory({
-  path: "./project.inlang",
-  fs,
-  project,
-});
-
-await project.close();
-```
-
-`loadProjectFromDirectory()` and `saveProjectToDirectory()` both accept `node:fs`. `saveProjectToDirectory()` writes translation files through import/export plugins. If no exporter plugin is configured, save the canonical packed file with `project.toBlob()` instead.
-
-## For coding agents and tool builders
-
-Target `.inlang` instead of inventing a custom JSON schema.
-
-Why target `.inlang`?
-
-- One file gives every tool the same data model for bundles, messages, variants, locales, metadata, and settings.
-- CRUD operations are available through the SDK instead of custom parsing and rewriting.
-- Version control via [lix](https://lix.dev) keeps localization changes reviewable and mergeable.
-- Plugins handle JSON, ICU, i18next, XLIFF, and other formats for compatibility.
-
-Do not:
-
-- Invent a custom `locales/en.json` schema as the project format.
-- Create a new localization config when a `.inlang` project already exists.
-- Edit generated or cached files in this directory.
-- Bypass `@inlang/sdk` when reading or writing `.inlang`.
-
-## Ideas for custom tooling
-
-- Translation health dashboard (missing/empty/stale messages)
-- Locale coverage report in CI
-- Auto-PR for new keys with placeholders
-- Migration tool between file formats via plugins
-- Glossary/term consistency checker
-
-## Data model ([docs](https://inlang.com/docs/data-model))
-
-```
-bundle (a concept, e.g., "welcome_header")
-  └── message (per locale, e.g., "en", "de")
-        └── variant (plural forms, gender, etc.)
-```
-
-- **bundle**: Groups messages by ID (e.g., `welcome_header`)
-- **message**: A translation for a specific locale
-- **variant**: Handles pluralization/selectors (most messages have one variant)
-
-## Common tasks
-
-- List bundles: `project.db.selectFrom("bundle").selectAll().execute()`
-- List messages for locale: `project.db.selectFrom("message").where("locale", "=", "en").selectAll().execute()`
-- Find missing translations: compare message counts across locales
-- Update a message: `project.db.updateTable("message").set({ ... }).where("id", "=", "...").execute()`
-
-## Links
-
-- [SDK documentation](https://inlang.com/docs)
-- [inlang.com](https://inlang.com)
-- [List of plugins](https://inlang.com/c/plugins)
-- [List of tools](https://inlang.com/c/tools)

package/templates-i18n/tanstack/src/paraglide/README.md

@@ -1,162 +0,0 @@
-# Paraglide JS Compiled Output
-
-> Auto-generated i18n message functions. Import `messages.js` to use translated strings.
-
-Compiled from: `./project.inlang`
-
-
-## What is this folder?
-
-This folder contains compiled [Paraglide JS](https://github.com/opral/paraglide-js) output. Paraglide JS compiles your translation messages into tree-shakeable JavaScript functions.
-
-## At a glance
-
-Purpose:
-- This folder stores compiled i18n message functions.
-- Source translations live outside this folder in your inlang project.
-
-Safe to import:
-- `messages.js` — all message functions
-- `runtime.js` — locale utilities
-- `server.js` — server-side middleware
-
-Do not edit:
-- All files in this folder are auto-generated.
-- Changes will be overwritten on next compilation.
-
-```
-paraglide/
-├── messages.js      # Message exports (import this)
-├── messages/        # Individual message functions
-├── runtime.js       # Locale detection & configuration
-├── registry.js      # Formatting utilities (plural, number, datetime, relativetime)
-├── server.js        # Server-side middleware
-└── .gitignore       # Marks folder as generated
-```
-
-## Usage
-
-```js
-import * as m from "./paraglide/messages.js";
-
-// Messages are functions that return localized strings
-m.hello_world();             // "Hello, World!" (in current locale)
-m.greeting({ name: "Sam" }); // "Hello, Sam!"
-
-// Override locale per-call
-m.hello_world({}, { locale: "de" });           // "Hallo, Welt!"
-m.greeting({ name: "Sam" }, { locale: "de" }); // "Hallo, Sam!"
-```
-
-## Runtime API
-
-```js
-import { getLocale, getTextDirection, setLocale, locales, baseLocale } from "./paraglide/runtime.js";
-
-getLocale();    // Current locale, e.g., "en"
-getTextDirection(); // "ltr" | "rtl" for current locale
-setLocale("de"); // Set locale
-locales;        // Available locales, e.g., ["en", "de", "fr"]
-baseLocale;     // Default locale, e.g., "en"
-```
-
-## Strategy
-
-The strategy determines how the current locale is detected and persisted:
-
-- **Cookie**: Stores locale preference in a cookie.
-- **URL**: Derives locale from URL patterns (e.g., `/en/about`, `en.example.com`).
-- **GlobalVariable**: Uses a global variable (client-side only).
-- **BaseLocale**: Always returns the base locale.
-
-Strategies can be combined. The order defines precedence:
-
-```js
-await compile({
-  project: "./project.inlang",
-  outdir: "./src/paraglide",
-  strategy: ["url", "cookie", "baseLocale"],
-});
-```
-
-See the [strategy documentation](https://paraglidejs.com/strategy) for details.
-
-## Markup (Rich Text)
-
-Messages can contain markup tags for bold, links, and other inline elements. Translators control where tags appear; developers control how they render.
-
-Important:
-- Tag names are app-defined. There is no built-in list of HTML tags.
-- `{#b}...{/b}` does not automatically render as `<b>...</b>`.
-- Renderers/snippets are looked up by the same tag name used in the message.
-
-### Message syntax
-
-```json
-{
-  "cta": "{#link to=|/docs| rel=$relationship @track}Read the docs{/link}",
-  "welcome": "{#b}Hi {name}{/b}{#icon/}"
-}
-```
-
-- `{#tagName}` opens a tag, `{/tagName}` closes it.
-- `{#tagName/}` creates a standalone tag.
-- Options: `to=|/docs|` or `rel=$relationship` (accessed via `options.*`).
-- Attributes: `@track` or `@variant=|hero|` (accessed via `attributes.*`).
-
-This is the default inlang message syntax. Paraglide's message format is plugin-based — you can use [ICU MessageFormat 1](https://inlang.com/m/p7c8m1d2/plugin-inlang-icu-messageformat-1), [i18next](https://inlang.com/m/3i8bor92/plugin-inlang-i18next), or other [plugins](https://inlang.com/c/plugins) instead.
-
-### Rendering markup
-
-Calling the message function still returns **plain text** (markup stripped):
-
-```js
-m.cta({ relationship: "noopener" }); // "Read the docs"
-```
-
-To render markup, use the framework adapter or the low-level `parts()` API:
-
-```js
-const parts = m.cta.parts({ relationship: "noopener" });
-// [
-//   { type: "markup-start", name: "link", options: { to: "/docs", rel: "noopener" }, attributes: { track: true } },
-//   { type: "text", value: "Read the docs" },
-//   { type: "markup-end", name: "link" }
-// ]
-```
-
-Framework adapters provide a `<ParaglideMessage>` component that accepts markup renderers:
-
-- `@inlang/paraglide-js-react`
-- `@inlang/paraglide-js-vue`
-- `@inlang/paraglide-js-svelte`
-- `@inlang/paraglide-js-solid`
-
-```jsx
-import { ParaglideMessage } from "@inlang/paraglide-js-react"; // or -vue, -svelte, -solid
-
-<ParaglideMessage
-  message={m.welcome}
-  inputs={{ name: "Ada" }}
-  markup={{
-    b: ({ children }) => <b>{children}</b>,
-    icon: () => <span aria-hidden="true" className="icon-wave" />,
-  }}
-/>
-```
-
-The available renderer/snippet names come from the message itself. You can inspect them through `message.parts()`, and TypeScript uses the same names to type-check your markup renderers.
-
-See the [markup documentation](https://paraglidejs.com/markup) for details.
-
-## Key concepts
-
-- **Tree-shakeable**: Each message is a function, enabling [up to 70% smaller i18n bundle sizes](https://paraglidejs.com/benchmark) than traditional i18n libraries.
-- **Typesafe**: Full TypeScript/JSDoc support with autocomplete.
-- **Variants**: Messages can have variants for pluralization, gender, etc.
-- **Fallbacks**: Missing translations fall back to the base locale.
-
-## Links
-
-- [Paraglide JS Documentation](https://paraglidejs.com)
-- [Source Repository](https://github.com/opral/paraglide-js)