Repository files navigation

The repository forhigh quality TypeScript type definitions.

You can also read this README inEspañol,한국어,Русский,简体中文,Português,Italiano,日本語 andFrançais!

Link toAdmin manual

Definitely Typed has recently changed to a properpnpm monorepo; you may want to reread this document for changes to the layout of packages in this repo.

At the very least, you may want togit clean -fdx the repo (ornode ./scripts/clean-node-modules.js on Windows) to clean upnode_modules and runpnpm install --filter . to install the workspace root. See further sections for more info onpnpm install.

This section tracks the health of the repository and publishing process.It may be helpful for contributors experiencing any issues with their PRs and packages.

• Most recent buildtype-checked/linted cleanly:
• All packages are type-checking/linting cleanly:
• All packages are beingpublished to npm in under an hour and a half:
• typescript-bot has been active on Definitely Typed
• Currentinfrastructure status updates

If anything here seems wrong or any of the above are failing, please let us know inthe Definitely Typed channel on the TypeScript Community Discord server.

See theTypeScript handbook.

This is the preferred method. For example:

npm install --save-dev @types/node

To install typings for a scoped module, remove the@ and add double-underscore after the scope. For example, to install typings for@babel/preset-env:

npm install --save-dev @types/babel__preset-env

The types should then be automatically included by the compiler.You may need to add atypes reference if you're not using modules:

/// <reference types="node" />

See more in thehandbook.

For an npm package "foo", typings for it will be at "@types/foo".

If your package has typings specified using thetypes ortypings key in itspackage.json, the npm registry will display that the package has available bindings like so:

If you still can't find the typings, just look for any ".d.ts" files in the package and manually include them with a/// <reference path="" />.

Definitely Typed only tests packages on versions of TypeScript that are less than 2 years old.

Definitely Typed only works because of contributions by users like you!

Before you share your improvement with the world, use the types yourself by creating atypename.d.ts file in your project and filling out its exports:

declare module"libname"{// Types inside hereexportfunctionhelloWorldMessage():string;}

You can edit the types directly innode_modules/@types/foo/index.d.ts to validate your changes, then bring the changes to this repo with the steps below.

Alternatively, you can usemodule augmentation to extend existing types from the DT module or use thedeclare module technique above which will override the version innode_modules.

Add to yourtsconfig.json:

"baseUrl":"types","typeRoots": ["types"],

Createtypes/foo/index.d.ts containing declarations for the module "foo".You should now be able to import from"foo" in your code and it will route to the new type definition.Then buildand run the code to make sure your type definition actually corresponds to what happens at runtime.

Once you've tested your definitions with real code, make aPRthen follow the instructions toedit an existing package orcreate a new package.

Once you've tested your package, you can share it on Definitely Typed.

1. Fork this repository.
2. Clone it.
   • The Definitely Typed repo is large; you may want to consider using a"blobless clone" to save time and space by passing--filter=blob:none when runninggit clone.
3. Installnode.
4. Runpnpm install.
   • pnpm install will install theentirerepository, including packages you may not be editing. If you'd like to install only a subset,you can runpnpm install -w --filter "{./types/foo}..." to install@types/foo and all ofits dependencies. If you need to run tests for packages thatdepend on@types/foo, you can runpnpm install -w --filter "...{./types/foo}..." to pull in all related packages for testing.

We use a bot to let a large number of pull requests to DefinitelyTyped be handled entirely in a self-service manner. You can read more aboutwhy and how here. Here is a handy reference showing the life cycle of a pull request to DT:

• Make changes. Remember toedit tests.If you make breaking changes, do not forget toupdate a major version.
• Runpnpm test <package to test>.

When you make a PR to edit an existing package,dt-bot should @-mention the package's owners.If it doesn't, you can do so yourself in the comment associated with the PR.

If you are the library author and your package is written in TypeScript,bundle the generated declaration files in your package instead of publishing to Definitely Typed.You can also generate declaration files from JavaScript files, using JSDoc for type annotations.

If you are adding typings for an npm package, create a directory with the same name.If the package you are adding typings for is not on npm, make sure the name you choose for it does not conflict with the name of a package on npm.(You can usenpm info <my-package> to check for the existence of the<my-package> package.)

Your package should have this structure:

Generate these by runningnpx dts-gen --dt --name <my-package> --template module.See all options atdts-gen.

If you have.d.ts files besidesindex.d.ts, make sure that they are referenced either inindex.d.ts or the tests.

Definitely Typed members routinely monitor for new PRs, though keep in mind that the number of other PRs may slow things down.

For a good example package, seebase64-js.

When a packagebundles its own types, types should be removed from Definitely Typed to avoid confusion.

You can remove it by runningpnpm run not-needed <typingsPackageName> <asOfVersion> [<libraryName>].

• <typingsPackageName>: This is the name of the directory to delete.
• <asOfVersion>: A stub will be published to@types/<typingsPackageName> with this version. Should be higher than any currently published version and should be a version of<libraryName> on npm.
• <libraryName>: Name of npm package that replaces the Definitely Typed types. Usually this is identical to<typingsPackageName>, in which case you can omit it.

If a package was never on Definitely Typed, it does not need to be added tonotNeededPackages.json.

Test your changes by runningpnpm test <package to test> where<package to test> is the name of your package.You need to run this from the DefinitelyTyped directory because individual package.jsons don't define test scripts.

This script usesdtslint to run the TypeScript compiler against your dts files.

Once you have all your changes ready, usepnpm run test-all to see how your changes affect other modules.

dtslint includes module format andpackage.json configuration checks from@arethetypeswrong/cli. The checks run only if a SemVer-major-compatible implementation package can be found on npm to compare against the DefinitelyTyped package. (DefinitelyTyped packages marked asnonNpm in theirpackage.json are skipped.)

Many packages currently fail theattw checks and need to be fixed. To allow us to make incremental progress, failedattw checks do not fail thedtslint run when the package is listed infailingPackages inattw.json, but they will still be reported in thepnpm test my-package output. If you fix the package, remove it fromfailingPackages so thatattw checks can start failingdtslint runs.

All problems reported byattw have documentation linked in the output. Some rules of thumb to help avoid problems:

• Thepackage.json in the DefinitelyTyped package must have matchingtype andexports fields if the implementation package uses them in itspackage.json. For example, if an implementationpackage.json looks like:

  {"name":"my-package","version":"1.0.1","type":"module","main":"dist/cjs/index.cjs","exports": {".": {"import":"./dist/esm/index.js","require":"./dist/cjs/index.cjs"        },"./subpath": {"import":"./dist/esm/subpath.js","require":"./dist/cjs/subpath.cjs"        }    }}

  then the DefinitelyTypedpackage.json should look something like:

  {"name":"@types/my-package","version":"1.0.9999","type":"module","types":"index.d.ts","exports":{".":{"import":"./index.d.ts","require":"./index.d.cts"},"./subpath":{"import":"./subpath.d.ts","require":"./subpath.d.cts"}}}

  Notice that eachexports subpath is reflected, and each JavaScript file has a corresponding declaration file with a matching file extension—a.d.ts file types a.js file, not a.mjs or.cjs file!

• When the implementation package usesmodule.exports = ..., the DefinitelyTyped package should useexport =, notexport default. (Alternatively, if themodule.exports is just an object of named properties, the DefinitelyTyped package can use a series of named exports.) The most common obstacle to correcting this problem is confusion about how to export types in addition to the primary export. For example, assume these types are incorrectly usingexport default:

  exportinterfaceOptions{// ...}exportdefaultfunctiondoSomething(options:Options):void;

  Changing theexport default to anexport = creates an error:

  exportinterfaceOptions{// ...}declarefunctiondoSomething(options:Options):void;export=doSomething;// ^^^^^^^^^^^^^^^^^// Error: An export assignment cannot be used in a module with other exported elements.

  To fix this, move the types inside a namespace with the same name as the function:

  declarenamespacedoSomething{exportinterfaceOptions{// ...}}declarefunctiondoSomething(options:doSomething.Options):void;export=doSomething;

If you need help fixing a problem, please ask in the DefinitelyTyped channel on theTypeScript Community Discord server.

If you are adding typings for an npm package, create a directory with the same name.If the package you are adding typings for is not on npm, set"nonNpm": true in thepackage.json, and make sure the name you choose for it does not conflict with the name of a package on npm.(You can usenpm info <my-package> to check for the existence of the<my-package> package.)

In rare occasions,nonNpm may be set to"conflict", which incidates that there is a package on npm with the same name, but the types intentionally conflict with that package.This can be true for packages which define an environment like@types/node or for dummy packages likeaws-lambda. Avoid using"conflict" where possible.

There should be a<my-package>-tests.ts file, which is considered your test file, along with any*.ts files it imports.If you don't see any test files in the module's folder, create a<my-package>-tests.ts.These files are used to validate the API exported from the*.d.ts files which are shipped as@types/<my-package>.They do not themselves ship.

Changes to the*.d.ts files should include a corresponding*.ts file change which shows the API being used, so that someone doesn't accidentally break code you depend on.For example, this change to a function in a.d.ts file adding a new param to a function:

index.d.ts:

- export function twoslash(body: string): string+ export function twoslash(body: string, config?: { version: string }): string

<my-package>-tests.ts:

import {twoslash} from "./"// $ExpectType stringconst result = twoslash("//")+ // Handle options param+ const resultWithOptions = twoslash("//", { version: "3.7" })+ // When the param is incorrect+ // @ts-expect-error+ const resultWithOptions = twoslash("//", {  })

If you're wondering where to start with test code, the examples in the README of the original package are a great place to start.

You canvalidate your changes withnpm test <package to test> from the root of this repo, which takes changed files into account.

Use$ExpectType to assert that an expression is of a given type and@ts-expect-error to assert that a compile error. Examples:

// $ExpectType voidf(1);//@ts-expect-errorf("one");

For more details, seedtslint readme.

If for some reason a lint rule needs to be disabled, disable it for a specific line:

// eslint-disable-next-line no-const-enumconstenumConst{One,}constenumEnum{// eslint-disable-line no-const-enumTwo,}

You can still disable rules with an .eslintrc.json, but should not in new packages.Disabling rules for the entire package makes it harder to review.

tsconfig.json should havenoImplicitAny,noImplicitThis,strictNullChecks andstrictFunctionTypes set totrue.

You may edit thetsconfig.json to add new test files, to add"target": "es6" (needed for async functions), to add to"lib" or to add the"jsx" compiler option.

TL;DR:esModuleInterop andallowSyntheticDefaultImports arenot allowed in yourtsconfig.json.

These options make it possible to write a default import for a CJS export, modeling the built-in interoperability between CJS and ES modules in Node and in some JS bundlers:

// component.d.tsdeclareclassComponent{​​​​​}​​​​​// CJS export, modeling `module.exports = Component` in JSexport=Component;// index.d.ts// ESM default import, only allowed under 'esModuleInterop' or 'allowSyntheticDefaultExports'importComponentfrom"./component";

Since the compile-time validity of the import inindex.d.ts is dependent upon specific compilation settings, which users of your types do not inherit, using this pattern in DefinitelyTyped would force users to change their own compilation settings, which might be incorrect for their runtime. Instead, you must write a CJS import for a CJS export to ensure widespread, config-independent compatibility:

// index.d.ts// CJS import, modeling `const Component = require("./component")` in JSimportComponent= require("./component");

This file is required and should follow this template:

{"private":true,"name":"@types/PACKAGE-NAME","version":"1.2.9999","projects":["https://aframe.io/"],"dependencies":{"@types/DEPENDENCY-1":"*","@types/DEPENDENCY-2":"*"},"devDependencies":{"@types/PACKAGE-NAME":"workspace:."},"owners":[{"name":"Your Name Here","githubUsername":"ghost"}]}

Apackage.json specifiesall dependencies, including other@types packages.

You must add non-@types dependencies tothe list of allowed external dependencies.Pikaday is a good example.These additions are approved by a maintainer, which gives us the chance to make sure that@types packages don't depend on malicious packages.

If the implementation package uses ESM and specifies"type": "module", then you should modify package.json to match:

{"type":"module"}

This also applies if the implementation package hasexports in its package.json.

Definitely Typed allowspeerDependencies inpackage.json.Peer dependencies can help prevent situations where a package manager unexpectedly installs too-new versions or more than one version of the same package.However, peer dependencies have downsides; package managers differ in their handling of peer dependencies (e.g.,yarn does not auto-install them,npm requires--legacy-peer-deps for mismatches).As such, PRs introducing new peer dependencies require maintainer approval and should be limited to specific circumstances.

In general, types packages should only have a peer dependency if the upstream package has a peer dependency on the same package (or its types).For example, a DT package for a React component can specify a peer dependency on@types/react@*, as the consumer will have needed to install@types/react to use JSX in the first place.If the consumer installs@types/react@16 in their project, but a newer version of@types/react is available on npm, the peer dependency may help the package manager choose@types/react@16 instead of that newer version.Similarly,chai-as-promised has a peer dependency onchai, so@types/chai-as-promised should have a peer dependency on@types/chai.

There are some cases where the upstream package does not have a peer dependency on the types package, but a peer dependency is still appropriate.These are typically cases where the upstream package extends another package and assumes it exists, soshould have declared a peer dependency as it extends another package, but did not.For example,chai-match-pattern extendschai, but does not declare a peer dependency onchai, but needs it to function.@types/chai-match-pattern should have a peer dependency on@types/chai.

If a package simply exposes types from another package as a part of its API due to a regular dependency in the upstream package, itshould not use a peer dependency.For example,express hasqs in its"dependencies". When users installexpress, they don't need to manually installqs. Likewise,@types/express has@types/qs in its"dependencies".It would be incorrect to declare@types/qs as a peer dependency of@types/express, since that would require some downstream consumers to manually install@types/qs.

This file defines which files are to be included in each@types package. It must take a specific form. For packages with only one version in the repo:

*!**/*.d.ts!**/*.d.cts!**/*.d.mts!**/*.d.*.ts

Which is to say "ignore all files, but don't ignore any declaration files". For packages that have more than one version in the repo, the "latest" version (at the top level) should contain something like:

*!**/*.d.ts!**/*.d.cts!**/*.d.mts!**/*.d.*.ts/v15//v16//v17/

Which is the same as the previous.npmignore but ignoring each of the versioned child directories.

CI will fail if this file contains the wrong contents and provide the intended value. No matter what this file contains, the publisher will only publish declaration files.

• First, follow advice from thehandbook.
• Formatting:dprint is set up on this repo, so you can runpnpm dprint fmt -- 'path/to/package/**/*.ts'.
  • Consider using the VS Code.vscode/settings.template.json (or equivalent for other editors) to format on save with theVS Code dprint extension
• function sum(nums: number[]): number: UseReadonlyArray if a function does not write to its parameters.
• interface Foo { new(): Foo; }:This defines a type of objects that are new-able. You probably wantdeclare class Foo { constructor(); }.
• const Class: { new(): IClass; }:Prefer to use a class declarationclass Class { constructor(); } instead of a new-able constant.
• getMeAT<T>(): T:If a type parameter does not appear in the types of any parameters, you don't really have a generic function, you just have a disguised type assertion.Prefer to use a real type assertion, e.g.getMeAT() as number.Example where a type parameter is acceptable:function id<T>(value: T): T;.Example where it is not acceptable:function parseJson<T>(json: string): T;.Exception:new Map<string, number>() is OK.
• Using the typesFunction andObject is almost never a good idea. In 99% of cases it's possible to specify a more specific type. Examples are(x: number) => number forfunctions and{ x: number, y: number } for objects. If there is no certainty at all about the type,any is the right choice, notObject. If the only known fact about the type is that it's some object, use the typeobject, notObject or{ [key: string]: any }.
• var foo: string | any:Whenany is used in a union type, the resulting type is stillany. So, while thestring portion of this type annotation maylook useful, it in fact offers no additional typechecking over simply usingany.Depending on the intention, acceptable alternatives could beany,string orstring | object.

TL;DR: do not modify.github/CODEOWNERS, always modify list of the owners inpackage.json.

DT has the concept of "Definition Owners" which are people who want to maintain the quality of a particular module's types.

• Adding yourself to the list will cause you to be notified (via your GitHub username) whenever someone makes a pull request or issue about the package.
• Your PR reviews will have a higher precedence of importance tothe bot which maintains this repo.
• The DT maintainers are putting trust in the definition owners to ensure a stable eco-system, please don't add yourself lightly.

To add yourself as a Definition Owner, modify theowners array inpackage.json:

"owners": [    {"name":"Some Person","githubUsername":"somebody"    },    {"name":"Some Corp","url":"https://example.org"    }]

Note that this list isnot used to provide credit for contributions; it is only used for managing PR reviews.

Once a week the Definition Owners are synced to the file.github/CODEOWNERS which is our source of truth.

Definitely Typed is one of the most active repositories on GitHub. You might have wondered how the project came to be. @johnnyreilly wrote a history of Definitely Typed. It tells the story of the early days of Definitely Typed, from a repository created by @borisyankov, to the point where it became a pivotal part of the TypeScript ecosystem.You can read the story of Definitely Typed here.

Themaster branch is automatically published to the@types scope on npm thanks toDefinitelyTyped-tools.

It depends, but most pull requests will be merged within a week.Some PRs can be merged by the owners of a module and they can be merged much faster.Roughly:

PRs which only change the types of a module and have corresponding tests changes will be merged much faster

PRs that have been approved by an owner listed in the definition'spackage.json are usually merged more quickly; PRs for new definitions will take more time as they require more review from maintainers. Each PR is reviewed by a TypeScript or Definitely Typed team member before being merged, so please be patient as human factors may cause delays. Check thePull Request Status Board to see progress as maintainers work through the open PRs.

For changes to very popular modules, e.g. Node/Express/Jest which have many millions of downloads each per week on npm, the requirements for contributions are a bit higher.Changes to these projects can have massive ecosystem effects and so we treat changes to them with a lot of care.These modules require both a sign-off from a DT maintainer and enthusiastic support from the module owners. The bar for passing this can be quite high and often PRs can go stale because it doesn't have a champion.If you're finding that no-one is committing, try to make your PR have a smaller focus.

npm packages should update within an hour. If it's been more than an hour, mention the PR number onthe Definitely Typed channel on the TypeScript Community Discord server and the current maintainer will get the correct team member to investigate.

If the module you're referencing is a module (usesexport), use an import.If the module you're referencing is an ambient module (usesdeclare module) or just declares globals, use<reference types="" />.

Then they are wrong and we've not noticed yet. You can help by submitting a pull request to fix them.

Yes, usingdprint.We recommend using adprint extension for your editor.

Alternatively, you can enable a git hook which will format your code automatically. Runpnpm run setup-hooks. Then, when you commit,dprint fmt command will be executed on changed files.

Pull requests do not require correct formatting to be merged.Any unformatted code will be automatically reformatted after being merged.

💡 If you're a VS Code user, we suggest copying the.vscode/settings.template.json file to.vscode/settings.json.That template sets thedprint VS Code extension as the default formatter in the repo.

Here are thecurrently requested definitions.

If types are part of a web standard, they should be contributed toTypeScript-DOM-lib-generator so that they can become part of the defaultlib.dom.d.ts.

If there's no source JavaScript code at all, for example if you're writing helper types or types for a spec, you should publish the types yourself, not on Definitely Typed.Because they're meant to provide types for existing JavaScript code,@types packages are not meant to be imported directly.That is, you shouldn't create a Definitely Typed package that's meant to be used likeimport type { ... } from "@types/foo".Nor should you expect to writeimport type { ... } from "foo" when there's nofoo installed.

This is different from providing types for a browser only JavaScript library or types for an entire environment like node, bun, et al.There, the types are either resolved implicitly or using/// <references types="foo" />.

Some packages, likechai-http, export a function.

Importing this module with an ES6 style import in the formimport * as foo from "foo"; leads to the error:

error TS2497: Module 'foo' resolves to a non-module entity and cannot be imported using this construct.

This error can be suppressed by merging the function declaration with an empty namespace of the same name, but this practice is discouraged.This is a commonly citedStack Overflow answer regarding this matter.

It is more appropriate to import the module using theimport foo = require("foo"); syntax.Nevertheless, if you want to use a default import likeimport foo from "foo"; you have two options:

• you can use the--allowSyntheticDefaultImports compiler option if your module runtime supports an interop scheme for non-ECMAScript modules, i.e. if default imports work in your environment (e.g. Webpack, SystemJS, esm).
• you can use the--esModuleInterop compiler option if you want TypeScript to take care of non-ECMAScript interop (since TypeScript 2.7).

Like in the previous question, refer to using either the--allowSyntheticDefaultImportsor--esModuleInteropcompiler options.

Do not change the type definition if it is accurate.For an npm package,export = is accurate ifnode -p 'require("foo")' works to import a module andexport default is accurate ifnode -p 'require("foo").default' works to import a module.

Then you will have set the minimum supported version by specifying"minimumTypeScriptVersion": "X.Y" inpackage.json.

However, if your project needs to maintain types that are compatible with, say, 3.7 and aboveat the same time as types that are compatible with 3.6 or below, you will need to use thetypesVersions feature.You can find a detailed explanation of this feature in theofficial TypeScript documentation.

Here's a short example to get you started:

1. You'll have to addtypesVersions topackage.json:

   {"private":true,"types":"index","typesVersions": {"<=3.6": {"*": ["ts3.6/*"] }    }}

2. Create the sub-directory mentioned in thetypesVersions field inside your types directory (ts3.6/ in this example).ts3.6/ will support TypeScript versions 3.6 and below, so copy the existing types and tests there.

3. Back in the root of the package, add the TypeScript 3.7 features you want to use.When people install the package, TypeScript 3.6 and below will start fromts3.6/index.d.ts, whereas TypeScript 3.7 and above will start fromindex.d.ts.

   You can look atbluebird for an example.

This may belong inTypeScript-DOM-lib-generator. See the guidelines there.If the standard is still a draft, it belongs here.Use a name beginning withdom- and include a link to the standard as the "Project" link inpackage.json.When it graduates draft mode, we may remove it from Definitely Typed and deprecate the associated@types package.

NOTE: The discussion in this section assumes familiarity withSemantic versioning

Each Definitely Typed package is versioned when published to npm.TheDefinitelyTyped-tools (the tool that publishes@types packages to npm) will set the declaration package's version by using themajor.minor.9999 version number listed inpackage.json.For example, here are the first few lines of Node's type declarations for version20.8.x at the time of writing:

{"private":true,"name":"@types/node","version":"20.8.9999"}

Because the version is listed as20.8.9999, the npm version of the@types/node package will also be20.8.x.Note that the version inpackage.json should only containmajor.minor version (e.g.10.12) followed by.9999.This is because only the major and minor release numbers are aligned between library packages and type declaration packages. (The.9999 is to ensure that local@types packages are always newest during local development.)The patch release number of the type declaration package (e.g..0 in20.8.0) is initialized to zero by Definitely Typed and is incremented each time a new@types/node package is published to npm for the same major/minor version of the corresponding library.

Sometimes type declaration package versions and library package versions can get out of sync.Below are a few common reasons why, in order of how much they inconvenience users of a library.Only the last case is typically problematic.

• As noted above, the patch version of the type declaration package is unrelated to the library patch version.This allows Definitely Typed to safely update type declarations for the same major/minor version of a library.
• If updating a package for new functionality, don't forget to update the version number to line up with that version of the library.If users make sure versions correspond between JavaScript packages and their respective@types packages, thennpm update should typically just work.
• It's common for type declaration package updates to lag behind library updates because it's often library users, not maintainers, who update Definitely Typed when new library features are released.So, there may be a lag of days, weeks or even months before a helpful community member sends a PR to update the type declaration package for a new library release.If you're impacted by this, you can be the change you want to see in the world and you can be that helpful community member!

❗ If you're updating type declarations for a library, always set themajor.minor version inpackage.json to match the library version that you're documenting! ❗

Semantic versioning requires that versions with breaking changes must increment the major version number.For example, a library that removes a publicly exported function after its3.5.8 release must bump its version to4.0.0 in its next release.Furthermore, when the library's4.0.0 release is out, it's Definitely Typed type declaration package should also be updated to4.0.0, including any breaking changes to the library's API.

Many libraries have a large installed base of developers (including maintainers of other packages using that library as a dependency) who won't move right away to a new version that has breaking changes, because it might be months until a maintainer has time to rewrite code to adapt to the new version.In the meantime, users of old library versions still may want to update type declarations for older versions.

If you intend to continue updating the older version of a library's type declarations, you may create a new subfolder (e.g./v2/) named for the current (soon to be "old") version and copy existing files from the current version to it.

When creating a new version folder, ensure that the version field ofpackage.json has been updated;pnpm will automatically resolve to this versioned package whenever it's needed. If other packages in the repo need to depend on this new version, ensure that theirpackage.jsons are also updated too.

For example, if we are creatingtypes/history/v2, itspackage.json would look like:

{"private":true,"name":"@types/history","version":"2.4.9999"}

Another package may select this version by specifying:

{"private":true,"name":"@types/browser-sync","version":"2.26.9999","dependencies": {"@types/history":"^2"    }}

Also,/// <reference types=".." /> will not work with path mapping, so dependencies must useimport.

@types packages always type packages of the same version, so@types/foo@5.4.x are forfoo@5.4.x.As a consequence, all changes, breaking or not, are published as patch revisions, unless paired with a major/minor bump to change the package version being targeted (coincidentally or not).

When it comes to breaking changes, DT maintainers consider the popularity of the package, the upsides of the proposed breaking change, the effort that will be required for users to fix their code, and whether the change could reasonably be delayed until it can be synced with a major bump of the upstream library.

The TypeScript handbook contains excellentgeneral information about writing definitions and alsothis example definition file which shows how to create a definition using ES6-style module syntax, while also specifying objects made available to the global scope. This technique is demonstrated practically in thedefinition forbig.js, which is a library that can be loaded globally via script tag on a web page or imported via require or ES6-style imports.

To test how your definition can be used both when referenced globally or as an imported module, create atest folder and place two test files in there. Name oneYourLibraryName-global.test.ts and the otherYourLibraryName-module.test.ts. Theglobal test file should exercise the definition according to how it would be used in a script loaded on a web page where the library is available on the global scope - in this scenario you should not specify an import statement. Themodule test file should exercise the definition according to how it would be used when imported (including theimport statement(s)). If you specify afiles property in yourtsconfig.json file, be sure to include both test files. Apractical example of this is also available on thebig.js definition.

Please note that it is not required to fully exercise the definition in each test file - it is sufficient to test only the globally accessible elements on the global test file and fully exercise the definition in the module test file or vice versa.

Types for a scoped package@foo/bar should go intypes/foo__bar. Note the double underscore.

This project is licensed under the MIT license.

Copyrights on the definition files are respective of each contributor listed at the beginning of each definition file.