meeko init-framework

meeko init-framework crea el starter del framework: rutas por archivos en app/pages, un layout que conserva el shell al navegar, estilos globales y la configuración mínima. No necesita server/runtime.ts ni Redis para empezar: en desarrollo las sesiones viven en memoria. No instala dependencias ni sobrescribe archivos.

Uso#

npx @meekojs/meeko init-framework tienda

Proyecto creado en C:\proyectos\tienda
Siguiente paso: cd C:\proyectos\tienda && npm install && npm run dev

Tipo#

meeko init-framework <directorio>

Parámetros#

Resultado#

tienda/
├── .env.example            las variables MEEKO_* comentadas
├── .gitignore              node_modules/, .meeko/, .env
├── README.md
├── meeko.config.ts         defineMeekoConfig({ layers: [], modules: [], imports: { serverDirs: [] } })
├── package.json
├── tsconfig.json           referencia .meeko/tsconfig.app.json, server y shared
├── public/.gitkeep
└── app/
    ├── app.meeko           el documento raíz
    ├── layouts/default.meeko
    ├── pages/index.meeko   render: "prerender", con un contador
    └── styles/main.css     estilos globales, que se cargan solos

package.json recibe estos scripts y fija @meekojs/meeko a la versión exacta de la CLI que lo creó, con @types/node, typescript y vite como dependencias de desarrollo:

Si la carpeta tenía pnpm-lock.yaml, el siguiente paso dice pnpm install && pnpm run dev.

Ejemplos#

Una aplicación nueva, de principio a fin#

npx @meekojs/meeko init-framework tienda
cd tienda
npm install
npm run dev      # http://localhost:4173
npm run check    # tipos y contratos
npm run build    # .meeko/output/node

Para npm start en producción hace falta un almacén de sesiones persistente (MEEKO_REDIS_URL o sessions en server/runtime.ts); véase meeko start.

Sobre un package.json existente#

Con una carpeta que sólo tiene pnpm-lock.yaml y este package.json:

{ "name": "tienda", "scripts": { "test": "node --test" } }

meeko init-framework .

Proyecto creado en C:\proyectos\tienda
Siguiente paso: pnpm install && pnpm run dev

{
  "name": "tienda",
  "scripts": {
    "test": "node --test",
    "dev": "meeko dev .",
    "check": "meeko check .",
    "build": "meeko build .",
    "start": "meeko start ."
  },
  "private": true,
  "type": "module",
  "engines": { "node": ">=24" },
  "dependencies": { "@meekojs/meeko": "1.6.0" },
  "devDependencies": { "@types/node": "^24.0.0", "typescript": "^7.0.2", "vite": "^8.3.5" }
}

Los campos, scripts y dependencias que ya existían se conservan; private, type y engines.node se fijan. El número de versión es el de la CLI que se ejecutó.

En un monorepo#

pnpm exec meeko init-framework apps/tienda
pnpm install
pnpm -F tienda dev

Los scripts usan . como directorio, así que funcionan con pnpm -F o desde la carpeta de la aplicación.

Errores comunes#

Una carpeta que no está vacía#

meeko init-framework tienda   # tienda ya tiene app/ o un README.md

El destino no está vacío: C:\proyectos\tienda (app, README.md). Desde 1.7, como en meeko init, el mensaje lista las entradas que lo impiden.

meeko init-framework tienda-nueva

Lockfiles sin su package.json#

# tienda tiene bun.lock o node_modules, pero no package.json
meeko init-framework tienda

El destino no está vacío: C:\proyectos\tienda (sin package.json): unos lockfiles sin su package.json son de otro proyecto. Una carpeta con sólo .git (git init tienda) sí se acepta desde 1.7; hasta 1.6 se rechazaba.

cd tienda && npm init -y && meeko init-framework .

Un package.json que ya define dev, check, build o start#

# package.json con "scripts": { "dev": "vite" }
meeko init-framework .

El destino ya define el script dev: C:\proyectos\tienda. No se escribe nada.

# renombra o quita el script y vuelve a ejecutarlo
meeko init-framework .

Notas#

• .meeko/ no se versiona. El .gitignore del starter lo excluye, igual que .env. Los tipos y entradas se regeneran con meeko dev o meeko check.
• Sin servidor que configurar. Las sesiones funcionan sin server/runtime.ts: en memoria en desarrollo y, en producción, en Redis con MEEKO_REDIS_URL. Añade server/runtime.ts con defineServerRuntime cuando necesites servicios, tu propio almacén o la política de Socket.
• .env.example. Documenta MEEKO_PORT, MEEKO_HOST, MEEKO_PUBLIC_ORIGIN, MEEKO_REDIS_URL, MEEKO_SESSION_TTL, MEEKO_SESSION_SAMESITE, MEEKO_TRUST_PROXY y, desde 1.8, MEEKO_TRUSTED_PROXIES (comentadas). Cópialo a .env: dev, build, start, preview y check lo leen.
• Versión exacta. El proyecto fija la versión de @meekojs/meeko con la que se creó; actualízala a mano con el gestor de paquetes.
• Windows y POSIX. El mensaje usa &&, que funciona en PowerShell 7, cmd y POSIX.

Relacionado#

• meeko initCrea un proyecto SSR independiente, sin el framework, con un componente .meeko, su servidor de Node y Vite.
• meeko devServidor de desarrollo de una aplicación full-stack, que prepara los tipos de .meeko/ y sirve la aplicación con Vite, SSR y HMR.
• meeko checkComprueba un proyecto completo, o un solo componente .meeko, con los diagnósticos de Meeko y TypeScript, y genera los tipos de .meeko/.
• defineMeekoConfigDeclara la configuración de meeko.config.ts con sus tipos (layers, módulos, autoimports, aliases, servidor, CSS, documento, sitemap y tema) sin cambiarla.
• Crear una aplicaciónMeeko como framework full-stack
• ConfiguraciónMeeko como framework full-stack