Using excel.d.ts in another project

[HoldYourWaffle]

office-js-docs-reference uses DT as the source of truth for its type definitions, which can be conveniently installed in a project with @types/office-js. Is there an equivalent for Office Scripts?

There seem to be two versions of excel.d.ts in this repository:

• generate-docs/script-inputs/excel.d.ts (declare syntax)
• generate-docs/api-extractor-inputs-excel/excel.d.ts (export syntax)

The latter seems to get generated based on the first by GenerateDocs.sh.

Can this first file be considered a "source of truth", or is there a better place to get these type definitions from?

[AlexJerabek]

Hi @HoldYourWaffle,

This came up in a Stack Overflow post a while back: https://stackoverflow.com/questions/71938117/excelscript-type-definnitions

Basically, the type definitions are shipped with Excel. This repo maintains a [copy of the .d.ts file](https://github.com/OfficeDev/office-scripts-docs-reference/blob/main/generate-docs/script-inputs/excel.d.ts to generate the reference documentation. This is the most up-to-date publicly accessible version of the type definitions.

If you're curious about the documentation generation, the process here is similar to that of the Office JS reference documentation, as documented here.

I'm going to close this issue, since there's not an actionable work item. Feel free to keep the discussion going, though.

[HoldYourWaffle]

Aaah interesting, that makes sense, thanks for the clarification!

Are there any plans to publish these definitions as an npm package, like office-js?
I could write a script to download the file from this repository, but that seems a little janky :P

[AlexJerabek]

We actually discourage people from using the npm package for office-js. It's better to use what's in the CDN because that'll always be up-to-date.

We have no plans to publish the @types of Office Scripts, since the only consumption of them is in the in-client Code Editor. What are you looking to do with the type definitions?

[HoldYourWaffle]

That's good to know, thanks for the heads up!

I'm looking into setting up a basic "traditional" development environment to work around office-scripts-docs#663 and various other limitations of the in-client editor (such as #305 and the lack of (reusable) modules).