Val Build IntelliSense

Val Build IntelliSense improves the Val development experience by providing Visual Studio Code users with advanced features such as validation errors, warnings and hot fixes.

Installation

Install via the Visual Studio Code Marketplace →

In order for the extension to activate you must have Val installed.

Features

Validation errors

View validation errors right in VS Code.

Apply hot fixes

Apply hot fixes on validation errors right from VS Code.

How it works

Every Val feature — validation errors, quick fixes, media path and route completions, remote upload and download, logging in — is served by @valbuild/language-server, which ships inside the Val your own project depends on. This extension resolves that server and runs it, one per Val root.

That is the whole design, and it is deliberate. The extension used to carry its own copy of Val: a re-implementation of module evaluation, its own schema walker, its own copy of Val's mime table, its own remote-upload client. One extension release therefore worked against one Val release, Val-specific fixes shipped on this repository's cadence rather than Val's, and no other editor could benefit.

Now the contract is plain LSP:

• A feature your Val gains works immediately, with no extension update.
• A feature your Val does not have is hidden, rather than answered wrongly.
• Other editors get the same features by launching the same binary. See packages/language-server/README.md in the Val repository for a Neovim configuration.

One server runs per Val root, because roots in a monorepo may pin different versions of Val.

What you need installed

The only requirement is that @valbuild/language-server resolves from your project. There is no minimum version of @valbuild/core or of any other Val package — the extension never checks one.

You do not install it yourself. It ships inside whichever Val package your project already depends on:

So if the extension reports that the language server could not be resolved, upgrade the package above that matches your project — @valbuild/next for a Next.js app — and it will come with it. For @valbuild/next and @valbuild/cli that means 0.98.0 or later.

@valbuild/core is versioned separately and never carries a language server (the server depends on core, so it could not without a cycle). A project that depends only on @valbuild/core needs one of the packages above added, not upgraded.

The extension does not hold a list of framework packages: it reads your package.json and resolves through the @valbuild/* packages you actually depend on. A Val package released after the extension was published therefore works without an extension update — which matters under pnpm, where a transitive dependency is reachable only through the package that depends on it.

Commands

Both moved from val. to valBuild. after 1.1.0, so a keybinding pointing at an old id needs updating. val. is the language server's namespace — the commands it serves (val.login, val.uploadRemote, val.downloadRemote) are registered under it, and a name used on both sides is a duplicate registration, which VS Code answers with an error that fails the server's whole handshake.

Val: Log In is the palette entry to use: it runs against the Val root of the file you are in, and says why nothing happened if no server is running there.

Settings

VAL_LANGUAGE_SERVER_PATH does the same as valBuild.languageServerPath and is used when the setting is empty.

Troubleshooting

Run Val: Show Language Server Info from the command palette. It reports the resolved server path, its version, which package it was resolved through, whether a setting or environment variable overrode it, the detected Val version, the negotiated protocol version, and the features the server actually serves.

Three situations have different fixes, and the extension tells them apart:

• Your Val predates the language server. Upgrade the package that carries it for your project; the notification offers the command for your package manager.
• You have Val libraries but no framework or CLI package. Add one — the language server travels inside them.
• The carrier package is new enough but the server will not resolve. Usually a broken or partial install; reinstalling dependencies fixes it. Under Yarn PnP there is no node_modules to resolve through at all, so set valBuild.languageServerPath.

Pointing valBuild.languageServerPath at a Val monorepo checkout's packages/language-server/bin.js is also how to develop against an unreleased Val.

Releasing

npm run release -- patch     # 1.0.23 -> 1.0.24
npm run release -- minor     # 1.0.23 -> 1.1.0
npm run release -- 2.0.0     # an explicit version
npm run release -- minor --dry-run

Publishing is driven by a tag: .github/workflows/publish.yml fires on v* and ships to both the Visual Studio Marketplace and the Open VSX Registry. The script is the rest of it — bump, commit, tag, push — with the checks that are only cheap to make before the tag exists.

It refuses to release from a dirty tree (vsce packages the working tree, not the commit), from a branch that has diverged from its remote, or onto a tag that already exists. It then rebuilds, relints, runs the client tests and verify-vsix.mjs, and asserts that package.json and both version fields in package-lock.json match the tag — the same assertion publish.yml makes, made where it is still easy to act on.

The push is the point of no return, so it asks first. --dry-run prints the plan and changes nothing; --skip-checks skips the rebuild when it has just run.