Repository navigation
Provide a back-compat mechanism for bundled .d.ts files in package.json #22605
Description
People are always excited to use new type system features in their programs or definition files.
However, if these developers are shipping a library with bundled type definitions, they can't use these features in an exposed way unless they are willing to force all TS consumers of the library to upgrade to a matching compiler version.
This leads to awkward trade-offs and end-user confusion when they upgrade eventually does happen.
There should be some way for library authors to say "Use this .d.ts file if you're on this version of TypeScript" so they can provide back-compat ranges. This could be based on semver ranges provided in package.json:
{
...
"types-compat": {
"<=2.3": "backcompat/index-2.3.d.ts",
"<=2.7": "backcompat/index-2.7.d.ts",
"*": "index.d.ts"
}
}
Activity
mhegazy commentedon Apr 5, 2018
RyanCavanaugh commentedon Apr 5, 2018
I would expect these files to be either hand-created, or generated through some downleveling process.
The model for DT doesn't apply here since people may need e.g. the runtime v12 of a library for bugfix/feature reasons but not be able to consume type syntax from that version
rbuckton commentedon Aug 15, 2018
A few comments:
"typesCompat"or"typesVersions"to"types-compat"."*"version mapping as we still need to include"types"as the default for older versions of TypeScript.rbuckton commentedon Aug 15, 2018
cc: Daniel Rosenwasser (@DanielRosenwasser) since we were discussing this feature this morning.
rbuckton commentedon Aug 15, 2018
I put together a proposal that is very similar to this, which also addresses my earlier comments.
The key differences are:
"typesVersion"instead of"types-compat"declare module) vs. a non-ambient module.I also describe a proposed structure for DefinitelyTyped packages that could be used by
types-publisherto automate package.json generation and package deployments.rbuckton commentedon Aug 15, 2018
I would also like to add that this would address a number of issues:
IteratorResultfrom an interface to a union type would break NodeJS types (as well ases6-shimandes6-collections)./// <reference lib="..." />in packages and remove empty forward-reference declarations for types likeIterator,AsyncIterator,IteratorResult, etc. (needed fornode,es6-shim,core-js, etc.)node,moment, etc.).AlexStacker commentedon Sep 19, 2018
Ryan Cavanaugh (@RyanCavanaugh) Seeing this I have an idea, I want to add the different language comment version in
.d.tsfile, and decide which version of the comment to use based on the environment variablelocalof tsconfig.json or vscode. Friendly tips when using vscode.