Naily's ArkTS Support: a Volar-based language server for HarmonyOS in VS Code

What the extension is and why it was written

The project is a VS Code extension for the ArkTS language, published on the Visual Studio Marketplace as vscode-naily-ets under the NailyZero publisher, and also on Open VSX. The repository description says it is for personal use, and the README explains the motivation directly: the existing ArkTS extensions in the VS Code marketplace were all very rudimentary, so the author decided to write one.

The implementation approach is stated in the same paragraph. It is built on Volar, the toolchain that powers the Vue language server, which is why the extension is able to give ArkTS the kind of language support that Volar gives Vue: a real TypeScript language service behind an extension host, with completion, navigation and diagnostics driven by the compiler rather than by regular expressions.

The repository is a pnpm workspace named @arkts/monorepo, and the tree shows why it is organised that way. There is a packages/ directory holding the individual packages, an ohos-typescript/ directory, a sample/ directory with a complete HarmonyOS project including build-profile.json5, oh-package.json5, hvigorfile.ts and an AppScope/ directory, an e2e/ directory, and the usual tooling files.

Three packages are published from it, and the release list shows them moving together: vscode-naily-ets, the extension itself, @arkts/language-server and @arkts/language-plugin. All three are at version 1.3.10, tagged on the same day, which is the pattern you want from a client and a server that have to agree.

The default branch is named next, which is an unusual choice and a deliberate one for a project tracking a platform that is itself called HarmonyOS NEXT.

The feature list, with the versions each part arrived in

The README annotates each feature with the extension version that introduced it, which is more useful than an unversioned list because it tells you what you get on a given release.

From 1.x come the core language features: complete syntax highlighting, completion, navigation and diagnostics for the ArkTS language. Also from 1.x is the ability to install and manage the OpenHarmony SDK, with automatic detection of the API version for the currently open project and a prompt offering to download or switch to the right one.

Version 1.1.6 added the resource reference work, and this is the feature the README lists with the most detail. It covers completion and navigation for the $r function, completion and navigation for module.json5 files, and clicking any json file under resources/element/ to find global references. The implementation comes from a separate Rust project, @arkts/project-detector, described as an hvigor project analyser.

Version 1.1.8 added module.json5 path completion and navigation, diagnostics for reference expression errors, and permission completion for requestPermissions.

Version 1.2.10 added the hvigor resource manager panel, with folder creation for resource qualifier directories and a resource reference index. Version 1.2.12 and later added one-click formatting from the context menu, with the formatter provided by the oxk toolchain, which the README says is written in Rust and is a fork of the oxc project, with a separate demo repository at ohos-rs/oxc-ark.

Version 1.3.0 added two substantial things: an emulator image manager consistent with the one in DevEco Studio, supporting creating and deleting devices and downloading and deleting simulator images, provided by @arkts/image-manager; and support for tasks.json and launch.json, so you can run an hvigor build and then run or debug on a simulator or a real device through the hdc command.

The snippets are described as basically the same as TypeScript's, with additions for ArkTS-specific constructs such as struct declaration.

The Rust components: formatter, project detector and image manager

Three of the extensions depend on Rust code, and that is the most interesting engineering decision in the project.

The first is the formatter. The README notes that the formatting is provided by the oxk toolchain, that the toolchain is written in Rust, and that it was forked and modified from the oxc project. The claim attached is that it is extremely fast. The reason to fork rather than to call an existing formatter is a practical one: the oxc project targets JavaScript and TypeScript syntax, and ArkTS is TypeScript with extensions, so a formatter that understands ArkTS needs the parser changed rather than the output configured.

The second is @arkts/project-detector, the hvigor project analyser that powers the resource reference features, the $r completion and the resource manager panel. The name suggests what it does: it reads the hvigor project structure so the extension knows where resources live and how they are referenced.

The third is @arkts/image-manager, which backs the simulator image manager and is described as being as consistent with DevEco Studio's equivalent.

The packaging shows the platform problem this creates. The dependency list includes platform-specific builds of project-detector for android arm eabi, android arm64, darwin arm64, darwin x64 and freebsd x64, each as a separate optional dependency. That is the standard approach for shipping a native binary in an npm package: one package per platform, each installed only when its platform matches, so that the extension works on the developer's machine without shipping every binary to everyone.

The @arkts/debugger and @arkts/language-service packages are workspace and catalog dependencies in the same set, and the ohos-typescript/ directory in the tree suggests a bundled or patched TypeScript for the ArkTS dialect.

Installing it and setting the SDK paths

Installation is through the Marketplace or Open VSX, and the README notes that you can also search for ArkTS Support inside VS Code directly.

The settings that matter are the SDK paths, and the README gives their relationship to a DevEco Studio installation explicitly, which is the most useful thing in the configuration table.

ets.sdkPath is the OpenHarmony SDK path, corresponding to the sdk/default/openharmony directory under a DevEco Studio installation. Changing this setting restarts the ETS language server, which the README states directly.

ets.baseSdkPath is where all versions of the OpenHarmony SDK get installed, defaulting to ${os.homedir}/OpenHarmony. That default differs from ets.sdkPath, and the distinction is worth understanding: one is where your SDKs live, the other is which one the extension is currently using.

ets.hmsPath is the HMS SDK path, and the README explains why it is a separate setting, because the HMS SDK is independent of the OpenHarmony SDK, and it corresponds to sdk/default/harmony under the DevEco Studio install directory.

ets.ignoreWorkspaceLocalPropertiesFile lets you stop the extension inferring the base SDK path from a local.properties file in the workspace.

The remaining settings cover behaviour. ets.lspDebugMode enables debug logging for the ETS language server. ets.linterVersion selects the version of the ArkTS linter to use, and can be set to off to disable the linter, with a default of 1.1. ets.resourceReferenceDiagnostic sets the diagnostic level for unmatched $r resource references, defaulting to error.

Two settings handle the simulator side. ets.localImagePath is where local HarmonyOS and OpenHarmony simulator images are stored, defaulting to ~/Library/Huawei/Sdk on macOS and %APPDATA%\Local\Huawei\Sdk on Windows. ets.imageConfigPath is where the HarmonyOS configuration lives, with different defaults per platform, including the DevEco Studio 6.0 directories on macOS and Windows.

The file icon theme is enabled through settings.json:

{
  "workbench.iconTheme": "arkts-icons"
}

The ArkTS Icons theme covers .ets, .hml and .json5 files alongside the usual web file types, and is aimed at mixed Nx monorepo projects where ArkTS and web code sit side by side.

JSON Schema coverage and the DevEco Studio parity goal

One feature is worth its own treatment because it is the quiet one: JSON Schema support for the platform's configuration files.

The README lists the files covered: build-profile.json5 at both module and project level, oh-package.json5 at both levels, code-linter.json5 at both levels, the key value configuration files such as color.json under resources/element/, module.json5, mock-config.json5, hvigor-config.json5, main_pages.json5, and AppScope/app.json5. The list ends with a note that more files will be supported in future.

The effect is that a typo in a configuration key is flagged as you type, with the allowed values known. For json5 files, which are not plain JSON and are not covered by the editor's built-in JSON support, that is a real improvement rather than a nicety.

The overarching goal is parity with DevEco Studio. The emulator image manager is described as consistent with the one in DevEco Studio, the hvigor task and launch configuration support exists so you can compile and debug from VS Code the way you would from the official IDE, and the resource manager panel mirrors the resource tooling there.

That framing explains the whole design. This is not an attempt to be a better editor for ArkTS than DevEco Studio; it is an attempt to give developers who live in VS Code the same capabilities, so that the choice of editor does not determine which tools they can use. The cost of that goal is the amount of platform-specific work it requires, from the Rust analyser to the native binaries per platform to the versioned settings that mirror an IDE whose own layout changes between releases.

Limits: a personal-use extension tied to a moving platform

Several limits are worth naming, some of which the README is explicit about.

The first is that the repository description says the extension is for personal use. It is published on the Marketplace and on Open VSX, it has a three-package release process, and the dependency list is extensive, but the framing is one maintainer's tool. That matters when you are deciding whether to depend on it in a team setting, because a team depends on the maintainer rather than on a support commitment.

The second is the coupling to the platform's moving parts. The extension depends on the OpenHarmony SDK and the HMS SDK being installed on your machine, on the presence of the OpenHarmony SDK under specific paths, and on hvigor, the platform's build tool, and on the hdc command for running on a device. Change any of those and the extension's job gets harder.

The third is the version drift between the extension and the platform. The feature list annotates capabilities with extension versions, but the platform SDK has its own API versions, and the extension's ability to detect and offer the right SDK is a best-effort. The ets.linterVersion setting defaults to 1.1, which is a specific linter generation.

The fourth is the native binary problem. Project-detector ships as separate per-platform packages, and a platform without a published binary gets no resource analysis at all. The list in the dependencies covers Linux, macOS, Windows and FreeBSD architectures, which is broad, but a platform outside that set is simply unsupported.

The fifth is the churn of the default branch and the version line. The default branch is next, and the last three published releases are all at 1.3.10 with the newest tagged on 2026-05-02, while the last push to the repository was on 2026-10-18. Work is happening on the branch and the published extension is months behind, so what you install from the Marketplace is not what the repository currently contains.

This extension against DevEco Studio and against a bare TypeScript setup

Two comparisons make the choice clearer.

The first is against staying in DevEco Studio. DevEco Studio is Huawei's own IDE for HarmonyOS and it has all of this functionality built in and supported: the same SDK management, the same emulator manager, the same hvigor integration, the same resource tooling, and a debugger that Huawei maintains. The difference in approach is the editor, not the tooling. If your work is HarmonyOS and nothing else, DevEco Studio is the supported path and this extension is a convenience for people who need VS Code for other reasons in the same day.

That reason is the real justification. A developer with an ArkTS module in a monorepo alongside React and TypeScript services does not want two IDEs, and the ArkTS Icons theme is explicitly aimed at that mixed Nx monorepo case. In that situation the extension's value is not that it does something DevEco Studio cannot, but that it keeps one editor open.

The second comparison is against setting up ArkTS files as plain TypeScript in VS Code. Without any extension, an .ets file gets the TypeScript language service's partial support, which means no ArkTS-specific completions, no $r resource awareness, no module.json5 knowledge and no JSON Schema. Given that ArkTS is TypeScript plus ArkUI decorators plus the resource reference syntax, that partial support stops well short of useful.

The choice therefore comes down to whether you are a HarmonyOS-only developer. If you are, use DevEco Studio and its debugger and its guaranteed SDK alignment. If you are working across a mixed codebase and want ArkTS to be a first-class citizen in your editor, this extension is the pragmatic answer, and the parts it has written itself, the Rust formatter and the project analyser, are what make it more than a thin wrapper.

Editorial conclusion

Adopt this extension if you write ArkTS outside DevEco Studio and want editor support that matches the official IDE, particularly the resource reference handling, the simulator tooling and the hvigor task integration. Do not adopt it if you already work entirely in DevEco Studio, where the same functionality is built in. Verify first that the OpenHarmony SDK and HMS SDK paths in your settings point at your installation, since the language server restarts when the SDK path changes, and that the API version detected for your project matches the SDK you have installed.

Frequently asked questions

Official sources

1. License: MIT
2. ohosvscode/arkTS on GitHub
3. Project website
4. README
5. Releases