# ace-builds: the pre-built Ace editor bundles and how to embed them > ace-builds is the packaged distribution of the Ace code editor, published as four pre-built source trees plus TypeScript types. It is a delivery artifact, not the editor's source of truth, and that distinction shapes how you install, upgrade and debug it. **ajaxorg/ace-builds** — Packaged version of Ace code editor - Repository: https://github.com/ajaxorg/ace-builds - Stars: 3,094 · Forks: 1,890 - Language: JavaScript - License: NOASSERTION - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/ajaxorg-ace-builds ## What ace-builds is, and who the package is actually for Ace is a code editor written in JavaScript. The ace-builds repository is not that editor's development home. The README states plainly that the repository has only generated files, and that issues, feature requests and questions belong in the ajaxorg/ace repository instead. Its issue tracker is disabled. So the audience is narrow and specific. You are building a page, an internal tool, a documentation site or a product that needs syntax highlighting and editing, and you do not want to run Ace's own build step. You want a directory of ready JavaScript you can drop behind a script tag or resolve through a bundler. That is the whole promise. If you intend to modify the editor's behaviour at the source level, this is the wrong repository and the README says so. The package.json confirms the shape of the artifact: name ace-builds, main pointing at ./src-noconflict/ace.js, typings at ace.d.ts, and a test script that is literally an echo of an error and a non-zero exit. There is no test suite here. That is consistent with a generated output repository, but it also means you should not expect the package itself to validate your integration. ## The four pre-built trees and what separates them The README lists four versions, and the difference between them is the whole design of this package. src is concatenated but not minified. src-min is concatenated and minified with uglify.js. src-noconflict is concatenated, not minified, and uses ace.require instead of require. src-min-noconflict is concatenated, minified and uses ace.require. The conflict axis matters more than the minification axis. The noconflict variants avoid claiming the global require, which is what you want when the host page already has a module loader or another library defining require. The min variants trade readability for bytes. Choosing wrongly produces confusing failures: a minified build in a debugging session, or a conflicting require breaking an unrelated script on the page. package.json resolves main to src-noconflict/ace.js, so a plain import of the package lands on the non-minified, non-conflicting build. That is a defensible default for correctness, and a heavier one for production. If bundle size matters, you will be pointing at src-min-noconflict explicitly rather than relying on the default entry. Types are shipped separately as ace.d.ts, ace-modes.d.ts and ace-modules.d.ts at the repository root, with a types/ directory alongside. The typings field points at ace.d.ts. Type coverage of a generated bundle is always a step behind the runtime, so treat the declarations as a convenience rather than a contract. ## Installing ace-builds and loading the bundles the README points to The README does not give an install command. It links the npm badge to the ace-builds package page and points readers at editor.html and the demo directory as the simple way of embedding Ace into a webpage. Start from those two files rather than from a snippet in this article, because the repository's own examples are the ones that stay in step with the generated bundles. The README states that the pre-built trees exist for convenience of embedding and names them: src, src-min, src-noconflict and src-min-noconflict. A page that loads one of them references the file inside that directory, and the noconflict variants are the ones that use ace.require instead of require. ```bash npm install ace-builds ``` That command follows from the npm badge and the name field in package.json. What it installs is the same generated set of directories you see in the repository, with main resolving to ./src-noconflict/ace.js. For bundler users, the repository ships webpack-resolver.js and esm-resolver.js at the root. These exist because Ace loads modes and themes by dynamic path at runtime, which bundlers cannot see. The README does not document how to wire either resolver, so read the files themselves before assuming an import will resolve. ## Where ace-builds becomes the wrong choice The clearest failure mode is a bug you want fixed upstream. This repository holds generated files and its issues are disabled by design. A pull request against a generated tree either gets overwritten by the next build or is rejected outright. The README redirects you to ajaxorg/ace for exactly this reason, and ignoring that redirect costs you time. The second limitation is version skew. The latest release listed is v1.5.0 from 2022-05-12, while package.json declares version 1.44.0 and the last push to the repository was on 2026-05-11. A tag and a package version that far apart is a signal to check which artifact you are actually consuming. If your lockfile pins the npm version and your documentation quotes the tag, you are describing two different things. The third is the missing test script. There is no automated check in this repository that your integration works. Anything you build on top of ace-builds is verified by your own tests or not at all. For a component that renders user input and handles keyboard events, that is a real gap. Finally, if you only need to display highlighted code with no editing, a full editor bundle is more machinery than the task requires. The demo directory includes a static-highlighter example, which is the honest starting point for that case. ## Ace in a React app, and how it differs from Monaco React usage is a common search around this project, and the mechanism is not React-specific. Ace attaches to a DOM node and manages that subtree itself. In React you create a ref to a div, call ace.edit on the node in an effect, and destroy the editor on unmount. The friction is that Ace owns the DOM inside the container, so React must not re-render over it. The repository's demo/iframe.html and demo/shadow-dom.html are the closest things to isolation examples, and neither is a React component. The natural alternative is Monaco, the editor behind VS Code. The difference is architectural rather than cosmetic. Monaco is distributed as an AMD-style module set with a worker-based language service layer, which gives it richer IntelliSense and diagnostics out of the box and a heavier setup. Ace is a single JavaScript editor with modes and themes loaded as separate files, which makes it trivial to drop behind a script tag and harder to get deep language intelligence from. If your requirement is a lightweight embedded editor with broad language modes, Ace's model fits. If your requirement is a full IDE-like experience with type-aware completion, Monaco's worker architecture is built for that and Ace's is not. A second alternative worth naming is CodeMirror, which follows a similar modular philosophy but with a different extension API. The practical distinction for a first integration is that Ace's pre-built trees give you a working editor with two script tags, while CodeMirror expects you to assemble the pieces you need. ## Maintenance signals, licence and the upgrade cost The repository is not archived, and its last push was on 2026-05-11. That is recent enough that the generated bundles are being refreshed, but the release history is thin: the only release listed is v1.5.0 from 2022-05-12, against a package.json version of 1.44.0. A generated-output repository often skips tagging, so this is not automatically alarming, but it does mean npm version numbers are the reliable upgrade signal and tags are not. Upgrade cost is low in the common case and awkward in the unusual one. Bumping the npm version replaces the generated files wholesale; you do not merge anything. But because modes and themes are separate files loaded by path, a version bump can change which paths exist. If you copied individual files out of src-noconflict into your own asset pipeline rather than importing the package, you own that diff manually on every upgrade. Importing the package and letting your bundler handle the resolver is the cheaper long-term arrangement. On licensing: package.json declares BSD-3-Clause, while the repository metadata reports NOASSERTION, meaning GitHub's classifier could not determine a licence from the repository contents. The LICENSE file at the root is the authoritative text, and it is the one to read. This is a factual discrepancy to resolve before shipping, not a legal opinion, and I am not giving one. ## Conclusion Adopt ace-builds if you want a code editor in a page without running Ace's own build pipeline: the four pre-built trees, the .d.ts files and the demo directory cover most embedding needs, and the npm package resolves to src-noconflict/ace.js by default. Do not adopt it if you need to patch editor internals, because this repository contains only generated files and its issues are disabled; work in ajaxorg/ace instead. Before wiring it into a build, verify which of the four variants your bundler resolves, whether you need the webpack-resolver.js or esm-resolver.js shim for your loader, and which mode and theme files you must load alongside the core. Check the LICENSE file for the exact terms, since the repository metadata and package.json disagree on the license identifier. ## FAQ ### What is ace-builds and how does it differ from the Ace editor repository? ace-builds contains pre-built, generated files for embedding Ace, while the editor's own source and issue tracker live in the ajaxorg/ace repository. The README states that issues are disabled here and directs bug reports and feature requests to ajaxorg/ace. ### How do I install ace-builds from npm? Install the ace-builds package with npm. The package.json main field points at ./src-noconflict/ace.js, so importing the package resolves to the non-minified, non-conflicting build by default. ### What is the difference between src-noconflict and src-min-noconflict? Both use ace.require instead of require, which avoids conflicting with a page's existing module loader. The src-min-noconflict variant is additionally concatenated and minified with uglify.js, while src-noconflict is not minified. ### Does ace-builds ship TypeScript types? Yes. package.json sets typings to ace.d.ts, and the repository root also contains ace-modes.d.ts and ace-modules.d.ts alongside a types/ directory. These declarations accompany the generated bundles. ### Which version of ace-builds should I pin? package.json declares version 1.44.0, while the only release listed is v1.5.0 from 2022-05-12, so the npm version number is the more useful upgrade signal. The last push to the repository was on 2026-05-11. ## Sources - [ajaxorg/ace-builds on GitHub](https://github.com/ajaxorg/ace-builds) - [Issues](https://github.com/ajaxorg/ace-builds/issues) - [README](https://github.com/ajaxorg/ace-builds/blob/master/README.md) - [Releases](https://github.com/ajaxorg/ace-builds/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ajaxorg-ace-builds