Add the final manual type declarations

.circleci/config.yml

@@ -126,9 +126,6 @@ jobs:
           name: Set npm auth token
           command: echo "//registry.npmjs.org/:_authToken=${NPM_AUTH_TOKEN}" >
             ${HOME}/.npmrc
-      - run:
-          name: Build packages
-          command: npm run build
       - run:
           name: NPM publish
           command: ./scripts/circleci-publish.sh
@@ -141,9 +138,6 @@ jobs:
           name: Set npm auth token
           command: echo "//registry.npmjs.org/:_authToken=${NPM_AUTH_TOKEN}" >
             ${HOME}/.npmrc
-      - run:
-          name: Build packages
-          command: npm run build
       - run:
           name: NPM publish
           command: ./scripts/circleci-publish.sh --tag=prerelease

.gitignore

@@ -1,5 +1,4 @@
 .husky/_
-packages/logger/**/*.d.*
 coverage
 node_modules/
 resources/logos/dist

docs/contributing.md

@@ -26,7 +26,6 @@ We're glad you want to contribute to Reliability Kit!
     * [Pull request scope](#pull-request-scope)
     * [Merging pull requests](#merging-pull-requests)
   * [Releasing](#releasing)
-    * [Generated files](#generated-files)
     * [Hard-coding the release version](#hard-coding-the-release-version)
     * [Correcting releases](#correcting-releases)
   * [Issue management](#issue-management)
@@ -174,7 +173,7 @@ The linters are also run on pull requests and linting errors will block merging,
 
 ### Type safety
 
-We do not write TypeScript in this project, but we _do_ write [thorough JSDoc](https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html) and test against it which gives us all the benefits of TypeScript ([more info](./design.md#languages)).
+We do not write TypeScript code, but we _do_ write [thorough JSDoc](https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html) and publish type declarations, then test against it which gives us all the benefits of TypeScript ([more info](./design.md#languages)).
 
 We do not compile the code in our packages, but we do check that all variables are set to the correct types. If there are any type errors then you should see these in your editor if you're using VS Code. Otherwise type checking can be manually run as part of linting:
 
@@ -269,16 +268,6 @@ If the PR is left alone, it will continue to be updated with new releases as mor
 
 Before approving and merging the release PR, make sure you review it. You need to check the package versions that it updates to make sure you’re only releasing the things you expect.
 
-### Generated files
-
-Before publishing npm packages we do generate TypeScript type declaration files (`.d.ts`) so that TypeScript-based projects which use Reliability Kit will get correct type hinting.
-
-If a release has caused issues with Type hinting or TypeScript-based projects compiling, then you can inspect the generated files by running the build command locally and viewing the `.d.ts` files in your editor:
-
-```
-npm run build
-```
-
 ### Hard-coding the release version
 
 Sometimes it's necessary to hard-code a release version, for example if commits have been pushed to `main` which don't match our [commit format](#commit-type-prefixes). A more common reason to do this is when you want to publish a prerelease package to experiment before marking it as stable (e.g. publishing a `v0.1.0` before `v1.0.0`).

docs/design.md

@@ -27,7 +27,7 @@ The combination of the above allows us to work on and publish the packages in th
 
 In terms of TypeScript, the key benefits are having type safety and type hinting in your editor. We can achieve both of these without writing TypeScript. Using [JavaScript with JSDoc comments to document types](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html), VSCode (used by the majority of our engineers) offers the same level of type hinting as it does with TypeScript. It's also possible to run the TypeScript type checker against JavaScript code to verify that everything is type safe (e.g. using `tsc --checkJS`).
 
-In order to be useful for TypeScript projects, we do still need to publish our modules with TypeScript type declaration files (`.d.ts`). We made this an automated step during publishing and when authoring modules you should still write JavaScript and JSDoc.
+In order to be useful for TypeScript projects, we do still need to publish our modules with TypeScript type declaration files (`.d.ts`).
 
 ### CommonJS
 

package.json

@@ -20,14 +20,10 @@
     "create-package": "./scripts/create-package.js",
     "lint": "npm run lint:eslint && npm run lint:tsc",
     "lint:eslint": "eslint .",
-    "lint:tsc": "npm run clean && tsc --project ./jsconfig.json",
-    "clean": "npm run clean:types",
-    "clean:types": "./scripts/clean-generated-types.sh",
-    "build": "npm run clean && npm run build:types",
-    "build:types": "tsc --project ./jsconfig.build.json",
+    "lint:tsc": "tsc --project ./jsconfig.json",
     "test": "npm run test:jest && npm run test:modules",
     "test:jest": "jest --silent",
-    "test:modules": "npm run build && npm run test --workspaces --if-present",
+    "test:modules": "npm run test --workspaces --if-present",
     "prepare": "husky",
     "postinstall": "npm run build:logos"
   },
@@ -40,14 +36,14 @@
     "@types/jest": "^29.5.12",
     "@types/node": "^20.12.7",
     "eslint": "^8.57.0",
-    "eslint-plugin-jsdoc": "^48.2.1",
+    "eslint-plugin-jsdoc": "^48.5.0",
     "eslint-plugin-prettier": "^5.1.3",
     "husky": "^9.0.11",
     "jest": "^29.7.0",
     "lint-staged": "^15.2.2",
     "prettier": "^3.2.5",
     "release-please": "^16.10.1",
-    "typescript": "^5.3.3"
+    "typescript": "^5.5.2"
   },
   "engines": {
     "node": "18.x || 20.x || 22.x",

packages/app-info/lib/index.js

@@ -1,6 +1,10 @@
 const path = require('node:path');
 const { randomUUID } = require('node:crypto');
 
+/**
+ * @import { SemanticConventions } from '@dotcom-reliability-kit/app-info'
+ */
+
 // This package relies on Heroku and AWS Lambda environment variables.
 // Documentation for these variables is available here:
 //
@@ -159,7 +163,7 @@ exports.herokuDynoId = process.env.HEROKU_DYNO_ID || null;
 exports.instanceId = randomUUID();
 
 /**
- * @type {import('@dotcom-reliability-kit/app-info').SemanticConventions}
+ * @type {SemanticConventions}
  */
 exports.semanticConventions = {
 	cloud: {