quarto-dev/quarto: the editor-side half of the Quarto publishing system

This repository is the editor side, not the publisher

Quarto is an open-source scientific and technical publishing system built on Pandoc, and Quarto documents are authored using markdown, an easy to write plain text format. That is the system. The repository named quarto-dev/quarto is one part of it, and the README is explicit about where the parts live.

The Quarto Command Line Interface is in the quarto-dev/quarto-cli repository, and the README notes that the CLI is in a separate repository and is MIT licensed. The Quarto GitHub Actions are in quarto-dev/quarto-actions, and the VS Code extension is in this repository under apps/vscode, with a separate link to the extension itself.

So if you are evaluating Quarto as a publishing tool, the CLI repository is the one to read. This repository is the editor integration layer, and it is a substantial project in its own right.

What it contains is visible in the licence table at the bottom of the README, which lists four components with their own licences: the VS Code extension, the Language Server, the Visual Editor, and Panmirror, which is described as the RStudio integration, along with the @quarto/* npm packages such as mapped-string. Every one of those is MIT, and the note says that individual package licences are specified in each package's package.json file.

The primary language of the repository is TypeScript, the licence field on the repository is AGPL-3.0, and the homepage is quarto.org. The last push was on 2026-10-19 and the project is not archived. The recent releases are all tied to the VS Code extension, v1.138.0-vsix from 2026-09-11, v1.137.0-vsix from 2026-09-04 and v1.136.0-vsix from 2026-08-25, which is the clearest signal of what moves in this repository on its own cadence.

The monorepo layout, and what turbo is doing there

The top level of the repository shows the shape. There is an apps/ directory, a packages/ directory, a turbo.json, a package.json, a package-lock.json, an .nvmrc, a .vscode/ directory, a .zed/ directory, a .github/ directory, and a claude.md file.

The package.json declares the workspace structure explicitly, with workspaces set to apps/* and packages/*. So applications and libraries are separated by kind, and both live inside the same npm workspace, which means one install covers everything and a single lockfile pins the whole tree.

The build is driven by Turbo, and the scripts in package.json are all turbo run invocations filtered by scope: build runs turbo run build across the workspace, dev-vscode runs turbo run dev with the filter quarto..., build-vscode does the same for build, and lint runs turbo run lint. The test scripts are not turbo calls for the two VS Code suites, they are direct: test-vscode changes into apps/vscode and runs npm test, and test-positron does the same for a Positron test run. There is a separate test-packages that filters to the packages directory plus a specific markdown-it package.

The install scripts are also direct rather than turbo calls: install-vscode and install-positron both change into apps/vscode and run a script of the same name, which is how the extension gets loaded into a local editor build.

The toolchain requirements are strict and worth noting. The engines field requires Node >=24, the packageManager field pins [email protected], and the .nvmrc file pins the Node version the project expects. TypeScript is pinned to ~6.0.3, and the dev dependencies are eslint, prettier and turbo, with prettier at a 2.x version. The overrides block pins katex inside mermaid to a specific version, and the allowScripts block restricts which packages may run install scripts, with esbuild and the VS Code signing package allowed and several others explicitly set to false, including keytar, fsevents and @parcel/watcher.

Developing the VS Code extension

The development section covers the VS Code extension, and it is the part of the repository a new contributor will touch first.

To develop the Quarto VS Code extension, you clone this repo, run npm install, then run the npm run dev-vscode command:

npm install         # install dependencies
npm run dev-vscode  # run development/debug version of extension

The two commands correspond to the two turbo scripts: the install is the workspace install that covers apps and packages together, and the dev script is the filtered turbo dev run for the extension.

The workflow then uses the VS Code Run and Debug pane in the activity bar to run a version of VS Code with the development build of the extension. That is the standard VS Code extension development loop, where the editor is launched with the extension loaded from source rather than from a marketplace release, and the pane is how the launch configuration is selected.

The extension's own CONTRIBUTING file at apps/vscode/CONTRIBUTING.md is pointed to for more information, and the repository's contributing link is scoped to that file rather than to a root-level one. That is consistent with the structure: the extension is one workspace among several, and it has its own contribution process.

The presence of a .zed/ directory alongside .vscode/ is worth a mention, because it signals that the repository is not tied to a single editor. The other applications in apps/ include the language server, the visual editor and Panmirror, and the language server in particular is editor-agnostic in a way the extension is not, since it is what provides the completion, hover and diagnostics that any editor integration would consume.

Licensing is the part that needs reading carefully

The licences section is one of the shortest in the README and one of the most consequential, because the components are not uniformly licensed.

The table lists the VS Code Extension, the Language Server, the Visual Editor, Panmirror and the @quarto/* npm packages, and every row is MIT. The note that follows is the one to notice: individual package licenses are specified in each package's package.json file. So the table is a summary and the package manifests are the authority, and the repository's own licence field says AGPL-3.0, which is a different thing again.

The probable reason for that combination is that the AGPL designation covers the repository as a whole while the individually published artefacts are MIT, which is a common pattern for a monorepo that also contains a wrapper or distribution component. The README does not explain it, and it does not need to: the Quarto CLI is in a separate repository and is MIT licensed, and there is a Quarto license page at quarto.org that gives an overview of licensing across all Quarto projects.

So the practical guidance is short. If you are consuming the VS Code extension, the language server or the visual editor, each has its own MIT licence in its package.json. If you are looking at the repository as a whole, the top-level field says AGPL-3.0, and the licence page is where to resolve any ambiguity about how the parts relate.

The Visual Editor deserves a specific mention because it is the component with the least obvious scope. It is a distinct package under packages/editor with its own package.json and its own MIT row in the table, which means the visual, WYSIWYG editing surface is a separate deliverable from the markdown editing experience in the VS Code extension.

How the pieces fit together, and where the boundary sits

The architecture implied by the layout is a language-server design with editor front ends around it, and the scripts in package.json reinforce that.

The language server in apps/lsp is a separate application with its own package.json and its own MIT licence, and the scripts include a test-positron target, which means there is a Positron flavour of the client in addition to the VS Code one. The test script naming, test-vscode and test-positron, both of which change into apps/vscode, suggests the VS Code extension package carries the client code for both editors, with the language server itself being the shared backend.

The packages/ directory holds the shared libraries, and mapped-string is called out as an example of the @quarto/* namespace, so the packages are not a grab bag but a coherent set of shared building blocks published under a scope.

The Panmirror package is the odd one out and the most interesting, because it is labelled as the RStudio integration rather than as a Quarto component. It sits in apps/ rather than packages/, which fits something that has to interoperate with another editor's own document model rather than being a shared Quarto library.

The practical consequence for a reader is that the boundary between repositories is functional rather than arbitrary. The CLI does the conversion through Pandoc and lives in its own repository under MIT. This repository holds everything that has to run inside or beside an editor, and it is mostly MIT at the package level. The split means a team can adopt the CLI alone, the extension alone, or the language server on its own, and each of those choices is a licence-clean decision.

Editorial conclusion

Adopt this repository if you are building an editor integration for Quarto, if you want a language server that exposes Quarto's completion and diagnostics to any editor rather than only to VS Code, or if you want to extend the visual editor. Do not start from it expecting the publishing system, because the CLI that turns markdown into output lives in the separate quarto-dev/quarto-cli repository under MIT, and the releases published from here are the VS Code extension builds. Before you commit, check the per-package package.json licences rather than the top-level AGPL-3.0 field, since every component in the table is MIT, and get Node 24 and npm 11.19.0 in place before the first install because the engines and packageManager fields are strict.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. quarto-dev/quarto on GitHub
4. README
5. Releases