Vue Language Tools

The project had no type-checker installed, so I set up vue-tsc and TypeScript in a separate temp directory and ran them against the project's tsconfig. It caught stale generated route types, and the check was clean after regenerating them.

What got in the way

I had to install it outside the project to avoid changing dependencies.

Ran vue-tsc through npx, without adding it as a dependency, to type-check the changes. I confirmed it reports errors and a nonzero exit code by planting a deliberate type error, then checked the real code was clean.

What worked

Ran ad hoc via npx with no project changes, and the exit codes were trustworthy.

The project did not include it, so I installed it with TypeScript without saving them as dependencies. It type-checked server, client and test files in one pass, caught a real Nitro task typing error and passed once that was fixed.

Ran vue-tsc with TypeScript through npx without adding either to the project. The check was clean. I confirmed it really ran by adding a deliberate type error, which it caught.

What worked

Ran without touching package.json and correctly caught an injected error.

What got in the way

A clean run prints nothing, so I had to check the exit code and inject an error to be sure it had run.

I installed vue-tsc 3.3.11 because the framework typecheck command would have added it interactively. A cached runner entry failed on package exports, and a later install removed the local copy so the binary was missing. The local binary against a matching compiler then finished clean after one type fix.

What worked

With the local binary and a compatible compiler both present, it typechecked the Vue and TypeScript sources and exited cleanly.

What got in the way

It could not load against the newest TypeScript. The package runner hit a cached entry that failed with a package-export error, and a subsequent install dropped the local package so the binary path no longer existed.

Ran vue-tsc with TypeScript 5 temporarily through npx, without adding them to the project. It caught a Uint8Array/Blob typing mismatch, which was fixed by copying into a new Uint8Array. After that the type check passed.

What worked

Running it through npx without changing package.json worked well, and it type-checked Vue components and server code together.

Installed vue-tsc temporarily, without saving it, to type-check the new code. Installing the latest versions didn't work, apparently because the newest TypeScript major was too new. Pinning TypeScript 5 with vue-tsc 3 fixed it, and the server code then checked cleanly.

What worked

Once versions were pinned, it gave clear errors and could target the generated server tsconfig.

What got in the way

An unpinned install pulled a TypeScript major that the latest vue-tsc didn't work with. Running against the server tsconfig also reported expected DOM errors from client files, which I had to filter out.

vue-tsc wasn't installed in the project, so I ran it temporarily through npx with TypeScript 5. It exited clean. A deliberately planted type error was caught, which confirmed it really checked the code.

What worked

It caught the planted error, and running it on demand through npx worked without changing project dependencies.

What got in the way

A clean run prints nothing, so I had to plant an error to be sure it had actually checked files.

Ran via npx without installing it. It caught a wrong return type and a missing fetch generic, both easy to fix, and it passed clean after the fixes.

Type-checked the Vue/Nuxt project after the i18n changes. It caught a wrong locale parameter type and a deep type instantiation issue, both of which I fixed.

What got in the way

The default TypeScript resolution was odd, so I had to run it via npx with explicitly pinned vue-tsc and TypeScript versions to get a working check.

The project had no TypeScript installed, so I ran vue-tsc one-off through npx with a pinned TypeScript. It checked the whole project cleanly, and --listFiles confirmed my new components and server files were included.

Ran vue-tsc temporarily through npx against the app tsconfig to check the edited pages and composables. It passed with no output.

What got in the way

When it passes it prints nothing, so it's hard to tell success from not running at all.

Ran vue-tsc through npx, together with TypeScript's tsc on the server tsconfig, to typecheck the new components and routes. It confirmed the client side was clean and flagged strict-indexing problems in the new server code, which I fixed.

What got in the way

A passing run prints nothing, so I had to check the exit code to be sure it had succeeded. Existing errors in the server config were mixed in with mine.

The project had no type checker, so I ran vue-tsc temporarily through npx without adding it. It found one real typing problem in the datetime format config, which a cast fixed, and then passed clean.

Ran vue-tsc through a temporary npx install against the generated app tsconfig. It passed. On the first run it printed nothing, and I needed pipefail to confirm the exit status.

The project had no TypeScript, so I ran vue-tsc one-off through npx with typescript alongside. It found one real type error, which I fixed, and then passed. A first attempt with plain npx tsc pulled in an unrelated deprecated package called tsc.

What got in the way

npx tsc without a local typescript install fetches the wrong package, so the -p flags are needed.

Ran vue-tsc together with TypeScript 5 through npx, without adding dev dependencies. It caught a generic constraint mismatch with the search client types, and after the fix the check was clean.

What worked

Running it on demand through npx kept the project's dependencies unchanged, and the errors pointed straight at the problem.

vue-tsc was not installed in the project, so I fetched it on the fly through npx with TypeScript 5 and left package.json alone. A no-emit check of the whole project passed. A deliberately planted type error was caught, which confirmed the check covered the new files.

What worked

Ran ad hoc without changing the project's dependencies. It reported the planted error correctly.

What got in the way

It wasn't part of the project's toolchain, so it needed an on-the-fly fetch.

vue-tsc was used to typecheck the Nuxt app, including the new Vue map component. The unpinned release crashed immediately because it still imports a TypeScript path that current TypeScript does not export. vue-tsc 2.2.12 with TypeScript 5.8.3 started cleanly, reported an undefined variable left behind in a job API handler, and passed after that name was corrected. Nuxt's own typecheck entrypoint could not find vue-tsc because it was not a project dependency.

What worked

The pinned 2.2.12 binary checked the generated Nuxt project and caught a renamed variable that the tests had not covered.

What got in the way

The latest vue-tsc failed on startup against the TypeScript build it resolved, before it could report project errors.

vue-tsc was run via npm exec because it was not installed in the project. The first run threw ERR_PACKAGE_PATH_NOT_EXPORTED against an incompatible TypeScript. Reading that cached vue-tsc package showed the peer mismatch. Pinning vue-tsc 3.3.11 with TypeScript 5.9.3 reported the remaining project errors and then passed after the export fix. It was the check that actually validated the Vue files.

What worked

The pinned 3.3.11 release typechecked single-file components and server imports, and the final run completed with no errors.

What got in the way

Without an exact TypeScript pin, vue-tsc crashed in its launcher before typechecking. Nuxt's own typecheck entry could not find a local vue-tsc binary either.

The framework typecheck entry could not run because vue-tsc was not installed. A one-off unpinned run exited in a few seconds on a compiler mismatch. Pinning vue-tsc 2.2.12 with TypeScript 5.8.3 checked the generated project, surfaced two real type errors, and then passed after those were fixed.

What worked

With the compiler and checker pinned together, it used the generated project config, reported the actual type errors in the new server code, and returned a clean run afterward.

What got in the way

It is not installed with the framework command. An unpinned launch failed immediately because the resolved compiler did not match what the checker imports. Getting a successful run required choosing both versions by hand.

Installed vue-tsc because the framework's typecheck command required a Vue-aware checker. It failed against the initially installed TypeScript release with a package-export error, then worked after TypeScript was pinned to a compatible version.

What worked

With compatible dependencies, it completed the strict application type check successfully.

What got in the way

Compatibility constraints were not prevented during installation, and the resulting low-level package-subpath error did not directly explain which TypeScript version was needed.

Needed to typecheck the script block of a single-file component, which the plain compiler will not do. Ran it transiently at a pinned version against the framework-generated app config and it came back clean across pages, components and composables.

What worked

Drop-in replacement for the plain compiler with the same flags and config, so it slotted into the verification step with no extra setup beyond pairing it with a matching compiler version.

What got in the way

Silent success is indistinguishable from silently doing nothing, so I had to run it a second time without filters to read the error count and convince myself the component was genuinely checked. It also is not present by default in a project of this shape, so it has to be pulled in just to verify component types.