ternjs/tern: a stand-alone JavaScript analyzer that editors call into

The editor-side problem Tern was built to remove

JavaScript tooling has a structural problem that typed languages do not: every editor that wants completion, go-to-definition or type display has to build its own understanding of the language. That work is duplicated across Emacs, Vim, Sublime Text, Eclipse, Atom, TextMate and gedit, and most of those clients are maintained by people who would rather not maintain a parser.

Tern's answer is to take the analysis out of the editor. The README describes it as a "stand-alone, editor-independent JavaScript analyzer that can be used to improve the JavaScript integration of existing editors." The analyzer runs as its own process, the editor talks to it, and the editor keeps only the parts that are genuinely editor-specific: key bindings, buffers, and how results are displayed.

The audience follows from that. Tern is for people writing editor plugins and for editors whose built-in JavaScript support is thin. The README lists existing plugins for Emacs (and Emacs company-mode), Vim, Sublime Text, Eclipse and the general Java API, Light Table, Atom, TextMate and gedit, plus built-in support in Brackets, Edge Code, CodeLite, vy and SourceLair. If your editor is on that list, someone has already done the client work. If it is not, you are the audience for the protocol, not for the bundled plugins.

How the analyzer, the server and the editor fit together

The repository layout shows the split clearly. lib/ holds the analyzer and lib/tern.js is the entry point named in package.json as "main". bin/ holds the executable named as "bin": "./bin/tern", which is what npm links as the tern command. plugin/ holds editor-side code, defs/ holds definition files describing library APIs, and doc/ holds the documentation the README points to. The repository also carries a .tern-project file at its own root, which is the same configuration file a user project is expected to provide.

The analyzer parses JavaScript with acorn, acorn-walk and acorn-loose, all listed as dependencies in package.json. acorn-loose matters for the editor case: it can parse source that is mid-edit and therefore not syntactically valid, which is the normal state of a file while someone is typing in it. enhanced-resolve, glob, minimatch and resolve-from handle the other half of the job: turning module specifiers into files, and deciding which files belong to the project being analyzed.

The data flow is request and response. The editor sends a query about a position in a file, the server answers with a list of completions, a definition location, a type, or documentation. The README does not document the wire format or the individual query types; it directs readers to the manual on the project page for that. So the architecture is visible from the repository, but the protocol details are not in the README.

Installing Tern and getting a first answer out of it

Tern is published on npm as tern, and package.json gives the current version as 0.24.3 with an MIT license. The package declares a bin entry, so a global install puts a tern command on your path:

npm install -g tern

After that, the command exists but has nothing to analyze until you tell it which files belong to your project. Tern reads a .tern-project file, and the repository keeps one at its own root as an example. The README does not spell out the keys of that file, so the shape of it has to be taken from the example the repository carries rather than from the README.

With a .tern-project in place, the server can be started from the project directory:

tern

What you should see is a process that stays in the foreground and waits for requests. It is not an interactive prompt and it does not print analysis results on its own. To see anything useful you need a client, either one of the editor plugins the README lists or your own code speaking the protocol. If nothing appears to happen after starting it, that is the expected behaviour, not a failure.

The test entry point is also declared in package.json, so the analyzer can be exercised without an editor at all:

npm test

That maps to node ./bin/test, which is the script package.json declares for "test".

Where Tern stops being the right tool

The most common mismatch is expecting Tern to be a finished product. It is an analyzer plus a set of clients, and the clients live in separate repositories: the README links out to tern_for_vim, tern_for_sublime, tern_for_gedit, atom-ternjs and tern.java rather than shipping them here. Installing the npm package gives you the server. It does not give you completion in your editor.

The second mismatch is configuration burden. Tern has no way to know which files are in your project or which libraries you use unless you describe them. The .tern-project file is how you do that, and getting it wrong produces the worst kind of failure: the server runs, answers requests, and returns results that reflect a partial view of your code. A missing library definition does not raise an error, it just means Tern knows less about that library than you do.

The third is scope. The dependencies in package.json are acorn, acorn-walk, acorn-loose, enhanced-resolve, glob, minimatch and resolve-from. That is a JavaScript parser, a walker, a tolerant parser, a module resolver and file matching. There is nothing here for TypeScript, JSX transformation, or languages that compile to JavaScript. The README does not claim otherwise, and the repository gives no sign of a type-checking pass comparable to a compiler. If you want errors about wrong argument types, this is not the tool that produces them.

Tern against a full language server

The obvious comparison is the Language Server Protocol approach, where an editor speaks a standardized protocol and each language ships its own server. The difference is in who defines the interface. Tern predates that standardization and defines its own request and response format, which is why each editor needs a Tern-specific plugin rather than a generic LSP client.

The practical consequence cuts both ways. On the plus side, a Tern client can be written against a smaller, JavaScript-specific surface, and the existing plugins are evidence that this has been done repeatedly. On the minus side, an editor that already has an LSP client gains nothing from Tern's protocol; adopting it means writing and maintaining a second integration path.

There is also a difference in what gets analyzed. Tern's design centers on inference over source as it exists, including source that does not parse, which is why acorn-loose is a dependency. A type-checker-based server starts from annotations and reports violations. Those are different products serving different questions, and Tern's choice is deliberate: it is answering editor queries about code that is being written, not auditing code that is finished.

Maintenance, licence and what a version bump costs you

The repository is not archived, and the last push was on 2026-05-14. The README gives no release cadence and no recent release information was retrieved, so there is no basis for describing how often versions ship.

The licence is MIT, stated in both the README and the license field of package.json. For most users that means permissive terms with the usual requirement to carry the notice, but the repository also links to a crowd-funding campaign that paid for the original work, which is context rather than a licensing condition. Nothing in the repository suggests a dual licence, a commercial tier, or a contributor licence agreement, and nothing here should be read as legal advice.

Upgrade cost is dominated by the .tern-project file and the editor plugin, not by the analyzer. The version in package.json is 0.24.3, and the dependency ranges are all caret ranges, so a fresh install resolves to the newest compatible acorn, glob and minimatch. A client written against an older server may need to track changes in the query layer, and the README does not document a compatibility policy between server versions and plugins. If you maintain a client, pin the server version you have tested against rather than relying on a floating install.

Editorial conclusion

Adopt ternjs/tern if you are writing or maintaining an editor integration and want inference, completion and definition lookup without writing a JavaScript type system yourself. Do not adopt it if you expect a finished tool: the repository ships the analyzer and a set of plugins, and the README points at the manual for the rest. Before committing, check that a client for your editor exists in the list the README gives, that your project's layout is expressible in a .tern-project file, and that the defs/ directory contains a definition file for every library you rely on.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. ternjs/tern on GitHub