Add type definitions to exports

[NikolasHaimerl]

The package does not support sufficient type definitions for strict type checking.

Could not find a declaration file for module 'index-provider-peer-id'. '.../deal-observer/node_modules/index-provider-peer-id/index.js' implicitly has an 'any' type.

Changes need to be done in:

• index-provider-peer-id
• spark-deal-observer
• spark-spot-check
• spark-checker

[bajtos]

This should be a one-line fix, see

https://github.com/CheckerNetwork/assert-ok-response/blob/bff5c4861e3a64e262b08bba370c6480b597c116/package.json#L7

[bajtos]

@juliangruber do you know if it's possible to tell npm (or np) to run a custom script before packaging the files to upload to npm?

We need to run tsc -p . to create or update .d.ts files in the dist folder.

[bajtos]

This should be a one-line fix, see

https://github.com/CheckerNetwork/assert-ok-response/blob/bff5c4861e3a64e262b08bba370c6480b597c116/package.json#L7

I take that back. We also need to include dist in the published package.

https://github.com/CheckerNetwork/assert-ok-response/blob/bff5c4861e3a64e262b08bba370c6480b597c116/package.json#L25-L28

[juliangruber]

@juliangruber do you know if it's possible to tell npm (or np) to run a custom script before packaging the files to upload to npm?

We need to run tsc -p . to create or update .d.ts files in the dist folder.

Yes! We use that in actions for example:

https://github.com/CheckerNetwork/publish-zinnia-module-action/blob/1f1a600fbc4d63a5166107912b954ced39de8b70/package.json#L12

[bajtos]

I prefer not to commit the dist files to git.

I found the relevant npm docs, the solution I was looking for is the prepare script:

https://docs.npmjs.com/cli/v8/using-npm/scripts?v=true#life-cycle-scripts

On the second thought, np runs npm test as part of the release process, and npm test is configured to call tsc -p ., so I think we don't need to add any prepare script to our packages that use np for the release process.

Thoughts?

[juliangruber]

I prefer not to commit the dist files to git.

This is required for security: What you install should be exactly what's committed to git. Programs like https://scorecard.dev flag your project if that's not the case.

[bajtos]

I prefer not to commit the dist files to git.

This is required for security: What you install should be exactly what's committed to git. Programs like https://scorecard.dev flag your project if that's not the case.

I see your point about security. However, I have a different understanding.

• dist contains auto-generated files.
• We have fully reproducible builds thanks to package-lock.json. The following process recreates the same dist files:

  git checkout vX.Y.Z
  npm ci
  tsc -p .
  

• Therefore, it's not necessary to commit dist files to git for auditing purposes.

Angular is an example of a popular project that does not commit dist to git:

• https://github.com/angular/angular/tree/19.2.5/packages/core - no dist folder there
• https://github.com/angular/angular/tree/19.2.5 - no dist folder there either
• https://github.com/angular/angular/blob/5b76da59c696c98c17db032e3abc0ff2e2e60b92/.gitignore#L3 - /dist is not committed to git

Jest does not commit build (the output of tsc) to git either:

• https://github.com/jestjs/jest/blob/4e56991693da7cd4c3730dc3579a1dd1403ee630/.gitignore#L18-L19
• https://github.com/jestjs/jest/tree/v29.7.0/packages/expect - no build directory there

On the other hand, TypeScript does commit lib (the output of the build process) to git tags:

• https://github.com/microsoft/TypeScript/tree/v5.8.2/lib

---

What's important to me: I am concerned about pull request diffs being too noisy due to auto-generated changes. If we can find a way to commit dist to the release tags only, as TypeScript does, then I am happy to do so.

[juliangruber]

What's important to me: I am concerned about pull request diffs being too noisy due to auto-generated changes. If we can find a way to commit dist to the release tags only, as TypeScript does, then I am happy to do so.

This is exactly what happens when you use the version script: CheckerNetwork/publish-zinnia-module-action@319eaae

[juliangruber]

I'm just trying to follow best practices here. One point is that if you don't commit dist, people need to trust that your builds are reproducible.

[bajtos]

What's important to me: I am concerned about pull request diffs being too noisy due to auto-generated changes. If we can find a way to commit dist to the release tags only, as TypeScript does, then I am happy to do so.

This is exactly what happens when you use the version script: CheckerNetwork/publish-zinnia-module-action@319eaae

I am afraid that example shows how the dist folder is committed back to the main branch. That's what I'd like to avoid.

https://github.com/CheckerNetwork/publish-zinnia-module-action/tree/main/dist

---

I don't want to block our progress here. Considering that the dist folder in this repository should be tiny, just a small .d.ts file, I am fine to keep dist in the version control, under the following conditions:

• dist is updated in sync with the source files. When I check out the repository, I want to have a consistent state. I don't want to get dist from the previous release alongside the latest source files.
• dist is as small as possible. In particular, it should contain .d.ts files only, no .js files. (See https://www.typescriptlang.org/tsconfig/#emitDeclarationOnly.)