chore(release): version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@runablejs/cli@1.0.0

Minor Changes

• #51 1e2cf51 Thanks @domutala! - Ship ready-to-run starter projects for Express, Fastify, NestJS, AdonisJS, Hono, and Koa.

• #51 d289327 Thanks @domutala! - Add runable create --module for directly scaffolding a Runable module, keep the default interactive prompt focused on application creation, and install the framework packages as module development dependencies.

• #49 8ea56a0 Thanks @domutala! - Add a runable mcp command that starts the @runablejs/mcp installation from the current Runable project.

• #42 8589e2c Thanks @domutala! - Add Agent Skills distribution and installation to the CLI: runable skills install detects the AI coding agents already in use in a project (Claude Code, OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode, Cline, or any other Agent Skills-compatible agent), installs Runable's official Agent Skills into the right destination for each (.claude/skills/, .cline/skills/, or the shared .agents/skills/, deduplicated when several agents share one), and never overwrites a locally modified or foreign Skill without --force. runable skills list (with a --json option) lists the Skills bundled with the installed CLI version. Skills are bundled with the package itself — installing them never requires network access and always matches the installed Runable version.

  Also, runable create now scaffolds an AGENTS.md file into every new or existing project it sets up, so AI coding agents understand a project's Runable conventions from the start.

Patch Changes

• #73 7c00343 Thanks @domutala! - Give every starter its own framework-specific gitignore file and Runable lifecycle scripts, and streamline the AdonisJS starter while retaining ESLint and Prettier.

• #63 4dc97c8 Thanks @domutala! - Wrap the NestJS starter initialization in a bootstrap function.

• #69 8841343 Thanks @domutala! - Add a configurable NestJS catch-all module and update the NestJS starter to register it.

• #63 e5785b2 Thanks @domutala! - Allow esbuild dependency scripts in generated pnpm projects so dependency installation completes without manual approval.

• #61 7d64d86 Thanks @domutala! - Ship CLI runtime packages as production dependencies so installed commands can resolve them.

• #67 02ebe9a Thanks @domutala! - Add the internal Runable welcome component and use it as the home page of every generated starter.

• #1 79877dd Thanks @domutala! - clean code

• #63 4dc97c8 Thanks @domutala! - Use the current CLI package version for runable and @runablejs/cli when creating projects and modules.

• #77 c72c87f Thanks @domutala! - Use RUNABLE_MODE instead of NODE_ENV to select Runable's production runtime.

• Updated dependencies [8841343, 10421c7, 78f1a56, 5bed854, b129483, f6c9a82, 61e3258, 6b0b398, 9cdc4da, 4dc97c8, 377d8e1, 02ebe9a, 3404609, ad00d67, 6910aaf, c5dfc80, c72c87f, 83d018f, 180a915, 9a99a77, 1ace040, c72c87f]:

  • runable@1.0.0

runable@1.0.0

Minor Changes

• #69 8841343 Thanks @domutala! - Add a configurable NestJS catch-all module and update the NestJS starter to register it.

• #51 78f1a56 Thanks @domutala! - Add an extendRoutes configuration hook for modifying the complete file-based route tree before Vue Router writes generated routes and declarations.

• #57 5bed854 Thanks @domutala! - Add an extendConfig hook that can mutate or replace the fully resolved Runable configuration.

• #51 3404609 Thanks @domutala! - Add a Nuxt-compatible useFetch composable with reactive requests and options, SSR-aware async data, caching, transforms, key picking, deduplication, timeouts, manual execution, and clearing.

• #46 180a915 Thanks @domutala! - Add runable/inspector, a public, read-only API for programmatically inspecting how Runable resolves a project: createRunableInspector({ rootDir }) returns an object with getProject(), getConfig(), getRoutes(), getLayouts(), getMiddlewares(), getPlugins(), getModules(), getAutoImports(), and refresh(). Every result is a plain, JSON-serializable value, and runtime environment variables follow Runable's existing public/private split — a private value's name is exposed, never its value. Built as the underlying primitive for future tooling (CLI diagnostics, IDE integrations, DevTools) to build on; it does not itself implement any of those.

  The Inspector itself never generates or modifies a Runable project/build file, never changes process.cwd(), and never touches the process-wide cache loadConfig()/useConfig()/useAllConfigs() use — each Inspector holds its own state, resolved and refreshed independently, so several can run concurrently for different projects (or alongside a live dev server in the same process) without their Runable-owned state interfering. This is powered by a new exported primitive, resolveConfigGraph(rootDir) (runable's root export), which the existing loadConfig() now also uses internally — the two no longer duplicate the config/module resolution logic. Note that resolving a project's config still executes its runable.config.* files and module setup() hooks — ordinary project code, not sandboxed, that can have its own side effects (env vars, filesystem writes, ...) outside this isolation guarantee. As an incidental fix from threading rootDir explicitly through module resolution, a module referenced by another (non-root) module by a bare package name now resolves that package from the referencing module's own directory instead of always from process.cwd().

• #49 9a99a77 Thanks @domutala! - Add resolveRoute(path) to runable/inspector: given an absolute path, resolves it against the project's routes using Vue Router's own matcher (the same one a real navigation would use), returning the matched InspectorRoute plus extracted params/query/hash, or null if nothing matches. Supports dynamic, optional, and catch-all params, nested routes, and definePageMeta({ path, name }) overrides. Like every other Inspector getter, it reflects state as of the last refresh().

Patch Changes

• #49 10421c7 Thanks @domutala! - Validate that dynamically loaded server entries export a render function before handling SSR requests.

• #59 b129483 Thanks @domutala! - Call each extendConfig hook with its own resolved configuration and options.

• #53 f6c9a82 Thanks @domutala! - Fix generated application TypeScript configuration paths so aliases, source includes, configuration files, and local module directories resolve correctly from the build directory.

• #75 61e3258 Thanks @domutala! - Inject Runable auto-imports and auto-components into application resources explicitly registered by installed modules.

• #71 6b0b398 Thanks @domutala! - Include the Oxc decorator runtime required by the compiled NestJS adapter.

• #73 9cdc4da Thanks @domutala! - Load the production SSR manifest without a JSON module import and remove an invalid Rolldown manifest option.

• #63 4dc97c8 Thanks @domutala! - Ship unctx as a runtime dependency so installed applications can load Runable's context implementation.

• #49 377d8e1 Thanks @domutala! - Isolate the application context for concurrent SSR requests, avoid generated type writes and redundant configuration loading during production rendering, and resolve production manifest exports and server entry paths correctly.

• #67 02ebe9a Thanks @domutala! - Add the internal Runable welcome component and use it as the home page of every generated starter.

• #82 ad00d67 Thanks @domutala! - Keep root lifecycle hooks working when the application renders through SSR or updates through HMR.

• #49 6910aaf Thanks @domutala! - Fix loadRuntimeEnv() (used internally when resolving runtime config, e.g. by runable/inspector's getConfig()) unconditionally writing an "injected env (...) from .env" notice to stdout via dotenv whenever a project's .env file defines any RUN_/VITE_-prefixed variable. This is now passed quiet: true, so loading runtime env stays silent on stdout — important for any host process that reserves stdout for something else, such as an MCP server speaking JSON-RPC over stdio.

• #80 c5dfc80 Thanks @domutala! - Rename the built-in welcome component file to match its public RunableWelcome name and load its scoped styles automatically.

• #77 c72c87f Thanks @domutala! - Serve generated client assets through every adapter in production.

• #77 83d018f Thanks @domutala! - Serve .txt production assets with the text/plain MIME type so browsers display them inline.

• #65 1ace040 Thanks @domutala! - Use the ESM Lodash build in browser runtime entries so Vite can load the merge helper without CommonJS interop errors.

• #77 c72c87f Thanks @domutala! - Use RUNABLE_MODE instead of NODE_ENV to select Runable's production runtime.

create-runable@1.0.0

Patch Changes

• #42 8589e2c Thanks @domutala! - Fix the bundled CLI resolution in the create-runable bin: it now resolves @runablejs/cli through the package's own export map instead of a hardcoded dist/index.js path, so it keeps working if that package's build output ever moves.
• Updated dependencies [7c00343, 4dc97c8, 8841343, e5785b2, 1e2cf51, d289327, 7d64d86, 8ea56a0, 02ebe9a, 8589e2c, 79877dd, 4dc97c8, c72c87f]:
  • @runablejs/cli@1.0.0