Migrate typings away from DefinitelyTyped

[Blake Regalia]

The RDFJS typings should be maintained and published by the RDFJS organization. Some of the issues with hosting the typings on DefinitelyTyped are:

• issues and PRs on DT are not linked to this organization and therefore do not undergo the same review process, nor are RDFJS org members notified. Issues and PRs should be tracked, discussed, reviewed, etc., on RDFJS GH org.
• DT maintainers are responsible for reviewing PRs and thus control releases; RDJFS should have authoritative control over publishing and maintaining releases.
• DT is useful for adding types to untyped JS projects, but (as far as I know) was never intended for defining interfaces of standardized specifications.

Several libraries are currently using the de facto @types/rdf-js package for importing RDFJS interface types. Open question is whether or not DT/TypeScript will allow upgrading this package so that it simply acts as a proxy for new @rdfjs/types package by importing and exporting it.

[Tomasz Pluskiewicz]

For reference, DT or DefinitelyTyped is this repository: https://github.com/DefinitelyTyped/DefinitelyTyped

[Ruben Verborgh]

+1 for taking control

Open question is whether or not DT/TypeScript will allow upgrading this package so that it simply acts as a proxy for new @rdfjs/types package by importing and exporting it.

If not, we deprecate.

[Ruben Taelman]

I think the safest option would be to make this repo a clone of DT where we accept (and discuss) changes to the RDF/JS typings, and push to the upstream DT when we reach a consensus.

While I agree that @rdfjs/types would be a much cleaner solution, the convention of using DT (and @types/* packages) may lead to unforeseen problems in the future.

At the moment I don't know of any specific problems that would occur, but I can for example imagine that there could be linting tools that have special behaviour when they encounter @types/* packages, and would therefore misbehave on @rdfjs/types.

[Tomasz Pluskiewicz]

On a closer look maybe it would not be as troublesome, at least for package consumers. Right now the types package pretends to describe rdf-js. A package which indeed do exist on NPM

I think that the path of least resistance is to revive that package and remove @types/rdf-js from DT. Any existing import {} from 'rdf-js' should just work because typescript tries to resolve *.d.ts files in the same way it resolves other modules, if I understand this correctly.

The issue I found is on the end of any @types/ packages which depend on the current @types/rdf-js. According to the readme of DT any package can actually have package.json dependencies to "real" packages with types. The only nuisance is that any such package has to be explicitly added to allowedPackageJsonDependencies.txt in DefinitelyTyped-tools.

[Alex Kreidler]

Hey all,

I think reviving the rdf-js package would definitely mean most people don't have to find and replace their existing imports. We could add a depracation notices to @types/rdf-js, and existing libraries would get a notice but still work.

However this could lead to incompatibility if we make updates to the new types and a package is using the old ones. Thus I think "ripping the band-aid off" might be thee best option. That could entail either

• @tpluscode 's idea of removing the DT package
• Moving the new types to a new import location like @rdfjs/types, which would force clients to update code. Then at least they'd recognize if we've updated the interfaces and would be able to update code.

Regardless, I think its great that we're moving to our own repo so we can keep the types consistent with the spec and implement more consistent versioning.
I personally have several times experience TS errors when using packages that depend on @types/rdf-js version 3 vs version 4, so I'm very hopeful this will improve interoperability.