types / _discussions Goto Github PK

This is a planning thread for mirroring @types from Definitely Typed as Github Packages. Github Packages are associated with an org which determines their npm scope. It will be @types in this case.
But Github Packages exist in a separate namespace from repos; they're required to have an associated repo but it can be named anything. It's not a one-to-one situation the way types currently is.

Here are the open questions I know of:

1. What to name the Definitely Typed mirror repo.
2. What to put in the mirror repo (if anything).
3. What to do with the existing, used repo-based-packages.
4. What to do with existing, unused repo-based-packages (which start with npm- and env- as far as I can tell).

Here are my initial answers:

1. probably DefinitelyTypedMirror since I think DefinitelyTyped would be too confusing.
2. Nothing? Or just a README explaining the purpose of the repo.
3. I don't understand how these repos are used compared to npm-published packages from DT. I don't think Github Packages will interfere since they are installed in a completely different way.
4. I don't think anybody uses these, and they are the majority of repos (208 of 231). It might be worthwhile to do something like renaming the org to typesOld, creating a new types org, and moving the 23 other repos over. (Note: Is renaming an org possible? I didn't know that.)

Hey folks,

from what I see this project seems to have a similar goal to http://definitelytyped.org/ I'm just curious as to why we have the split and why I would use this over definitelytyped?

Cheers!

Hi,
This post is a suggestion to add general purpose types that others can rely on.
I would like to increase the number of lib-* types and other such type definitions that are not tied to a single library. Currently there are only two "lib" repositories: lib-json-schema and lib-http-status-codes. We could do more. There are many occasions when I need a type that is not tied to a library. I often end up writing my own ad-hoc definitions but having a standardized representations would help. I believe that this organization is the best place to host them.

Here are some concrete examples.

package.json, tsconfig.json

We could provide interfaces for popular JSON files. Typescript exposes definitions for parsed compiler options but not for "tsconfig.json" files. While writing build tools, being able to have a typed package.json would also help. We could also provide a generic Json type (more restrictive than any), types for web extension manifests, bower files, etc.
In addition to providing type information, it could also leverage doc comments to provide quick documentation.

Semantic types

This is mostly about providing aliases for primitive types to hint the usage, even if the compiler does not use it. Concretely, I often like to type my functions this way:

type PosixPath = string;
type Uint8 = number;

// ...

function readFirstByte(path: PosixPath): Uint8 {
  // ...
}

Typescript sees it as readFirstByte(path: string): number but as a developer, displaying the arguments or jumping to the declaration allows me to quickly understand that it's not any string but a POSIX path.
We could provide a library with commented aliases explaining the semantics of each alias to facilitate documentation purposes. Instead of repeating the description of an Uint8 I could generate documentation to link to the "canonical" description. Given the huge variety of string types, it could be nice to agree on some relation between a name and definition that can be used across the ecosystem.
Here are some example for strings: JsonString, Hex, Uuid, Host, MediaType, Cidr, CssColor, ClassName, Uri, SysPath, WinPath, PosixPath...

Node components

Node has a big API. If you need the types for only part of the API (for example streams or event emitters), you have to pull the whole definitions. It means that you create globals when in fact you may only want the event emitter types to expose a compatible implementation (for example for browsers). We could try to modularize the Node definitions, and eventually turn the Node definitions into a simple aggregation of smaller type definitions.

Utility types

I am not sure if those are still needed now that the standard lib comes bundled with many utility types. But we could have a package providing types of the same sort as Partial<T> or MapLike<T>. I no longer really rely on this sort of helper types so I am not sure if it's really needed but it's an idea.

What do you think about it? If such "general-purpose" types are created, how should they be published? They don't really belong to @types since they are not attached to a single library. They would fit nicely with typings but its deprecated. We could simply publish those as standalone npm packages using the old typed- prefix. (typed-package.json for example).