CLI Reference
vastx-native create <name> [--app-id com.example.app] [--platforms ios,android] [--link /path/to/vastx-native]
vastx-native init [ios] [android] # add to an existing project
vastx-native dev <ios|android> [ns run flags...]
vastx-native build <ios|android> [ns build flags...]
vastx-native doctor # check the project, then run `ns info`
vastx-native keystore create --alias <name> [--output ./release.keystore]
vastx-native analyze <ios|android> # bundle size report → report/report.html
vastx-native lint # catch a navigate() call to a route that doesn't exist
vastx-native clean # remove platforms/, hooks/, and cached build artifacts
vastx-native version [show] # show the current version + versionCode
vastx-native version bump <major|minor|patch>
vastx-native version sync # write the current version to native platform files
vastx-native mcp # start the bundled MCP server over stdio
dev/build forward any flags after <ios|android> straight to the real ns run/ns build — nothing NativeScript supports is off-limits.
For a signed Android release, generate a keystore once and set the environment variables it prints (never written to disk):
npx vastx-native keystore create --alias my-app
# then, once VASTX_NATIVE_KEYSTORE_* is set in your shell/CI secrets:
npx vastx-native build android --release
--link points the generated project's vastx-native dependency at a local checkout (a file: spec, so npm symlinks it) instead of a published release. Both use the prebuilt dist/ committed with the framework, so installing an app never compiles the framework:
vastx-native create myapp --link ../vastx-native
Auto-imports
Composables — both vastx-native's own (useDevice, useWebSocket, ...) and anything you add yourself under app/composables/ — are usable in any page or component with no import statement, the same DX Nuxt itself gives you.
Two real limitations, worth knowing:
- Only composables/utils are covered, not your own custom
.vuecomponents — those still need a normal explicit import. vue-tsc/your editor's TS server will still flag a name used only inside<template>and never referenced in<script>— reference it once in<script>instead (acomputed()is usually the natural fix).
Plugins
A "vastx-native plugin" is just an ordinary npm package that exports one or more useXxx() composables — install it like anything else. If it needs native setup (a Gradle dependency, an Android permission, an iOS Info.plist entry, ...), list it in nuxt.config.ts:
export default defineNuxtConfig({
native: {
plugins: ['some-vastx-native-plugin']
}
})
vastx-native init/dev/build will then look for a "./vastx-native" subpath export on that package and, if present, call its ensure(projectRoot, platforms) function — the same idempotent pattern this framework uses for its own native setup. A plugin with no such export is left alone.
App release versioning
package.json's own version field is the single source of truth, plus a nativeVersionCode field for Android's separate integer build number:
npx vastx-native version # show the current version + versionCode
npx vastx-native version bump patch # 1.0.0 (1) -> 1.0.1 (2), synced automatically
npx vastx-native version sync # re-sync current values without bumping
MCP server (agent-driven dev workflow)
Run npx vastx-native mcp from an app project to start the bundled stdio MCP server — no separate repository clone or server folder needed. It exposes doctor, build, lint, clean, analyze, device listing, install + launch, and log reading as MCP tools, so any MCP-speaking AI agent (Claude Code, Claude Desktop, anything else) can drive a project directly instead of shelling out blind.
Repository layout
src/ the Nuxt module (composables, components, route generation)
cli/, bin/ the vastx-native CLI (native bootstrap + ns run/build orchestration)
playground/ example Nuxt app consuming the module
vscode-extension/ the VS Code extension (separate package.json/build)
mcp-server/ bundled MCP server exposing the dev workflow to AI agents