| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Name | Name | Last commit date | ||
|---|---|---|---|---|
Sorry, we had to truncate this directory to 1,000 files. 1,214 entries were omitted from the list. | ||||
The repository for high quality TypeScript type definitions.
Also see the definitelytyped.org website, although information in this README is more up-to-date.
See the TypeScript handbook.
This is the preferred method. This is only available for TypeScript 2.0+ users. For example:
npm install --save-dev @types/nodeThe types should then be automatically included by the compiler. See more in the handbook.
For an NPM package "foo", typings for it will be at "@types/foo". If you can't find your package, look for it on TypeSearch.
If you still can't find it, check if it bundles its own typings. This is usually provided in a "types" or "typings" field in the package.json, or just look for any ".d.ts" files in the package and manually include them with a /// <reference path="" />.
These can be used by TypeScript 1.0.
You may need to add manual references.
DefinitelyTyped only works because of contributions by users like you!
Before you share your improvement with the world, use it yourself.
To add new features you can use module augmentation. You can also directly edit the types in node_modules/@types/foo/index.d.ts, or copy them from there and paste inside of declarations.d.ts and follow the steps below.
Once you've tested your package, you can share it on DefinitelyTyped.
First, fork this repository. Then inside your repository:
New work should generally be done on the types-2.0 branch. If you want your changes to be available to typings users, then you may edit master instead.
When you make a PR to edit an existing package, dt-bot should @-mention previous authors. If it doesn't, you can do so yourself in the comment associated with the PR.
If you are the library author, or can make a pull request to the library, bundle types instead of publishing to DefinitelyTyped.
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 use npm info foo to check for the existence of the foo package.)
Your package should have this structure:
| File | Purpose |
|---|---|
| index.d.ts | This contains the typings for the package. |
| foo-tests.ts | This contains sample code which tests the typings. This code does not run, but it is type-checked. |
| tsconfig.json | This allows you to run tsc within the package. |
index.d.ts should start with a header looking like:
// Type definitions for foo 1.2
// Project: https://github.com/baz/foo
// Definitions by: My Self <https://github.com/me>
// Definitions: https://github.com/DefinitelyTyped/DefinitelyTypedThe Project link does not have to be to GitHub, but prefer linking to a source code repository rather than to a project website.
tsconfig.json should look like this:
{
"compilerOptions": {
"module": "commonjs",
"target": "es6",
"noImplicitAny": true,
"strictNullChecks": true,
"baseUrl": "../",
"typeRoots": [
"../"
],
"types": [],
"noEmit": true,
"forceConsistentCasingInFileNames": true
},
"files": [
"index.d.ts",
"foo-tests.ts"
]
}These should be identical accross projects except that foo-tests will be replaced with the name of your test file, and you may also add the "jsx" compiler option if your library needs it.
DefinitelyTyped 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, see base64-js.
When a package bundles its own types, types should be removed from DefinitelyTyped to avoid confusion. Make a PR doing the following:
The types-2.0 branch is automatically published to the @types scope on NPM thanks to types-publisher. This usually happens within an hour of changes being merged.
Changes to the master branch are also manually merged into the types-2.0 branch, but this takes longer.
If the module you're referencing is an external module (uses export), use an import. If the module you're referenceing is an ambient module (uses declare module, or just declares globals), use <reference types="" />.
Currently we don't support this, though it is planned. If you're adding a new major version of a library, you can copy index.d.ts to foo-v2.3.d.ts and edit index.d.ts to be the new version.
Usually you won't need this. When publishing a package we will normally automatically create a package.json for it. A package.json may be included for the sake of specifying dependencies. Here's an example. We do not allow other fields, such as "description", to be defined manually. Also, if you need to reference an older version of typings, you must do that by adding "dependencies": { "@types/foo": "x.y.z" } to the package.json.
Then they are wrong. You can help by submitting a pull request to fix them.
If you're targeting types-2.0, write it like the types-2.0 definitions. If you're targeting master, we may change it to the new style when merging from master to types-2.0.
Here are the currently requested definitions.
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.
| Back | FazBrowse Home | New Git URL |