auto-generate type definitions from the json schema

[k-yle]

Besides from iD, there are several typescript projects which use this library. Currently, each project has to write their own type-definitions (see examples from overpass-turbo and osmapp). This is inconvenient and the definitions could easily become out-of-date.

This PR uses json-schema-to-typescript to generate TS definition files for the main JSON files in dist/*. This means that the next release of @openstreetmap/id-tagging-schema will include .d.json.ts files - example here

Examples:

import fields from "id-tagging-schema/dist/fields.json";
fields // type-definitions are available for fields

// and definitions can be imported by name, like `Field` or `Preset`
import type { /* ... */ } from "id-tagging-schema";

[tordans]

This looks great. I really like to see more TS in our projects. It will make working with them a lot easier.

[tyrasd]

It would be preferable if we could keep the no-await-in-loop linter rule. If the specific use here makes the file more easily readable, it's better to only disable the rule on that particular occurrence.

PS: for the types definitions to be imported as

import type { Field } from '@openstreetmap/id-tagging-schema';

we'd need to include "types": "./dist/index.d.ts" in package.json, right?

[k-yle]

done, also added ignoreMinAndMaxItems due to #242

[tyrasd]

//ping @k-yle: IIRC when I tested this, the generated type definitions were only usable if I include "types": "./dist/index.d.ts" in package.json¹, or is that not necessary?

Footnotes

1. See https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#including-declarations-in-your-npm-package ↩

[k-yle]

@tyrasd yes that's correct, that snippet will need to be added to id-tagging-schema's package.json, not the package.json in this repo

[tyrasd]

Aaah, yes, that makes sense. Sorry, I was once again confused by there being two different repositories for the tagging schema 🙈