office-js: the issue tracker for Office add-ins, not the library itself

A repository whose main job is the issues tab

The README is unusually direct about what this repository is for. It says the GitHub repository is primarily used to report issues found in the Office JavaScript APIs, and that the npm package associated with the repository is no longer officially supported.

So the code you can read here is not what most add-ins run. The Office JavaScript APIs are the platform that lets a web application reach into a Word document, an Excel workbook, an Outlook mail message or a calendar item. The add-in itself is HTML, CSS and JavaScript, and it runs in Office on the web, on Windows, on Mac and on mobile, using those familiar web technologies.

The repository layout matches a support project rather than a product. At the top level there are dist/ and embedded/, which are the packaged forms of the library, a package.json, an issue-scripts/ directory, a deployment.script/ directory, a .travis.yml file, SECURITY.md and LICENSE.md. There is no src/ tree of a modern application, no test suite in the usual layout, and no documentation directory, because the documentation lives on learn.microsoft.com instead.

For a developer evaluating the platform, that means this repository answers two questions: how do I report a problem, and how do I load the library. Everything else is elsewhere.

The npm package is the thing to stop using

The most consequential sentence in the README is that the npm package is no longer officially supported, and that your add-in should get the JavaScript library from the Office content delivery network. The stated reason is that this ensures essential product updates are served quickly to Office Add-ins.

The reference is a single script tag:

<head>
    ...
    <script src="https://officeapis.public.onecdn.static.microsoft/1/office.js" type="text/javascript"></script>
</head>

The README explains what that does: the Office JavaScript API files are downloaded and cached the first time the add-in loads, so the add-in is using the most up to date implementation of Office.js and its associated files for the specified version.

The trade-off is the one every CDN reference carries. You give up the ability to pin an exact library version, because the URL resolves to whatever Microsoft currently serves, and you add a network dependency to the first load of your add-in. The mitigation is caching, and the URL path carries a version segment that Microsoft documents separately, including a separate path for preview APIs.

The package.json in the repository still describes the npm artefact, with the name @microsoft/office-js, the version 1.1.10, the files list of dist and embedded, and an engines field requiring node at 6.9.4 or later. Its scripts object is empty, and its bugs field points at the Stack Overflow office-js tag rather than the issue tracker, which is a leftover of the package era.

TypeScript users get their definitions from DefinitelyTyped

If you write an Office Add-in in TypeScript, the IntelliSense definitions do not come from this repository. The README says TypeScript definitions for Office.js are available on DefinitelyTyped, and it separates the stable and preview channels.

For the release version of Office.js, the definitions live at the DefinitelyTyped office-js path, and the npm package is @types/office-js, installed as a development dependency:

npm install @types/office-js --save-dev

For the preview version of Office.js, there is a separate office-js-preview definitions path and a separate package, @types/office-js-preview, installed the same way with npm install @types/office-js-preview --save-dev.

The split matters because the preview channel exposes APIs that are not yet in the shipped library, so a project that references the preview types has to decide which script tag it loads. The README points to the documentation page on referencing the Office JavaScript API library from its CDN for that, including how to reference preview APIs.

Because the type definitions live in DefinitelyTyped, the version of the types you compile against can move independently of the library the CDN serves, which is another way for a project to end up type checking against an API surface that differs from the runtime.

Bugs, feature requests and questions go to three different places

The README separates the support channels, and following the wrong one is the most common way to waste time with this platform.

For bugs in the Office JavaScript APIs, the issues tab of this repository is the place. The README asks you to check whether the issue is already reported and add context or reproduction steps if so, and otherwise to select New issue, choose Bug report, and provide as much detail as possible. It commits that a member of the team will respond within 1 to 2 business days.

It also points you to a separate Office Add-ins Known Issues page for current known issues, so a bug you are about to report may already be documented there.

Feature requests are explicitly not for the issue tracker. Requests for new platform features should be raised at the Microsoft 365 Developer Platform Tech Community site, where upvoted requests are considered by the team for inclusion into the product.

Questions about how to develop add-ins and use the APIs are also not for the issue tracker. They belong on Stack Overflow with the office-js tag, or on Microsoft Q&A with the Office Development tag, and the README notes that those locations are monitored by a community of experts that includes members of the product team.

So: the tracker for defects, the community site for roadmap asks, the Q&A sites for usage help.

Government clouds need their own CDN reference

One deployment detail in the README deserves its own mention because it changes the code. Government clouds may need to reference a special version of the CDN, and the README links to the guidance for deploying Office Add-ins on government clouds.

That is a hard requirement rather than a preference. If your add-in ships into a government tenant and the script tag points at the public CDN, the add-in either fails to load its API or loads it from an endpoint that the tenant's network policy blocks. The fix is a different URL, which means the URL has to be a configuration value in your project rather than a constant pasted into an HTML file, if you support both destinations.

The other thing the README describes is the caching behaviour of the CDN reference, which is the part that decides whether your add-in feels fast on a second load. The library files are cached on first load, so a user who has run your add-in before is not paying the download again, provided the caching behaves as documented on the platform your add-in runs on.

Nothing in the README describes an offline or air gapped mode for the library, and none of the documented references point anywhere other than the Microsoft CDN, so an environment that cannot reach Microsoft endpoints is outside what this material covers.

Commits in 2026, but no release since 2018

The maintenance picture here is unusual, and it is worth stating plainly rather than guessing at.

The repository is not archived and the last push was on 2026-10-16, so the project is still being worked on. The default branch is release, which is a branch name that signals a release-oriented workflow rather than the develop-and-main pattern most projects use.

The release history, though, has one entry: v1.1.10, dated 2018-09-20. The version field in package.json is the same 1.1.10. So the tags and the npm package are frozen, while the repository itself continues to receive commits, presumably to the library sources and to the tooling that publishes to the CDN.

That gap is not an inconsistency so much as a description of the architecture. The CDN is the delivery mechanism, and it is updated by the product pipeline rather than by a public tag, which is exactly why the README tells you not to install the npm package. If you were expecting to pin a version of office-js in your own package.json, that expectation is exactly what the README tells you to drop.

The licence is filed as a custom licence that GitHub cannot classify, with the terms in the LICENSE.md file at the repository root, so read that file if you intend to redistribute the library files yourself. The project follows the Microsoft Open Source Code of Conduct, and SECURITY.md covers how to report a security problem.

Editorial conclusion

office-js is worth bookmarking for anyone building an Office Add-in, because it is the official bug channel for the APIs and it documents the CDN reference pattern that most add-ins now use, along with the DefinitelyTyped packages for IntelliSense. It is the wrong place to look for the library source, for a build pipeline, or for a version you can pin, since the npm package is no longer officially supported and the repository has published no release since v1.1.10 on 2018-09-20. Before you depend on the CDN reference, confirm that your deployment target permits the request to officeapis.public.onecdn.static.microsoft, and check the government cloud guidance if you deploy in one, since a special CDN version may be required.

Frequently asked questions

Official sources

1. Issues
2. OfficeDev/office-js on GitHub
3. Project website
4. README
5. Releases