This service is now part of microsoft/DefinitelyTyped-tools.
If you need to update allowedPackageJsonDependencies.txt (formerly named dependenciesWhitelist.txt), please do so at its new location.
This repo has moved:
Home Page: https://github.com/microsoft/DefinitelyTyped-tools/tree/master/packages/publisher
License: MIT License
This service is now part of microsoft/DefinitelyTyped-tools.
If you need to update allowedPackageJsonDependencies.txt (formerly named dependenciesWhitelist.txt), please do so at its new location.
Might be worth warning authors of packages that are dependent on @types/module
, when the definitions are about to be updated?
See here webpack-env.d.ts
in DefinitelyTyped: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/types-2.0/webpack/webpack-env.d.ts
But I cannot find @types/webpack-env
in npm, and installing @types/webpack
only gives node_modules/@types/webpack/index.d.ts
which does not contain the contents of webpack-env.d.ts
.
So it is possible in another way?
In https://github.com/Microsoft/types-publisher/blob/master/src/lib/package-generator.ts#L93, the dependencies are listed with asterisks. This means any version is compatible. If someone is using an older commit hash and can not update, this will immediately break on them as the dependencies will be bumped to the latest incompatible version.
The only values included in a directory in DefinitelyTyped should be an entry point .d.ts
(usu. index.d.ts
), other .d.ts
files referenced by that, and (optionally) test files and a partial package.json
.
Currently we also store old versions of a definition in the same directory; we should move these to their own directory instead (or just throw them out).
For example, every .d.ts
file in bingmaps
except for the index is currently ignored.
The README for this project launches into detail with no explanation of what this project is for. I'm using another GitHub lib which is using this, and it seems broken, but I have no idea what this library's purpose is.
Could you add some context information to the ReadMe please?
Server has been up as of 2019-01-29T18:07:45.628+0000
I think I've brought this up a few times privately now, but I recently saw microsoft/TypeScript#10250 and thought I should bring it up publicly now. Having a dependency on an environment that does not exist can be bad and easily introduces numerous bugs. The most prolific is when DefinitelyTyped started introducing global Promise
typings when you may have been running on node 0.10 which does not have promises. However, the same thing can exist else - for instance, using or exposing a specific method from http.Request
or Buffer
, etc. can create subtle bugs in the runtime while compile time tells you everything is good.
When publishing to NPM, that package could list a peer dependency on the real NPM module. This would improve the issue where the @types/
version and the real version could become out of sync, as NPM will warn the user. By default, it could probably be tagged using semver semantics as ^
(caret) of the current version that was typed.
Each time we do a full publish we should create a Git issue where the body is the summary log and the first comment is the detailed log.
In instructions on how to use @types
, type packages are installed with --save
and not --save-dev
.
Why is this?
I wouldn't expect that I need the types outside of my development environment?
There should be a note about it in the various readmes.
@types/orchestrator should depend on @types/q (this is even listed in the orchestrator readme), but there is no dependency in the package.json.
We should wrap up the stuff from /lib
into an NPM package so we can use it from the definition-tester project and reuse its logic
We should allow a folder structure which is
/some-lib
redirect.json
The contents of redirect.json
would be something that tells types-publisher how to enlist and parse the linked repo. We can probably start with just git URLs and expand as needed
There's nothing stopping a user from publishing a thing that imports a package even if said package wasn't listed as a dependency in package.json
See title
Packages in DefinitelyTyped should use global references for this, rather than ../some-other-library
.
When the definition-parser scans for .d.ts files, it should also look in sub-folders.
https://github.com/Microsoft/types-publisher/blob/master/src/lib/definition-parser.ts#L74
This affects react-router and other modules. See microsoft/TypeScript#9488
@types/react-router
depends on @types/history
, yet there is no depenency entry in the package.json.
Here is the output of npm info @types/react-router
{ name: '@types/react-router',
description: 'TypeScript definitions for react-router v2.0.0',
'dist-tags': { latest: '2.0.26-alpha' },
versions:
[ '2.0.13-alpha',
'2.0.14-alpha',
'2.0.19-alpha',
'2.0.20-alpha',
'2.0.21-alpha',
'2.0.22-alpha',
'2.0.23-alpha',
'2.0.24-alpha',
'2.0.25-alpha',
'2.0.26-alpha' ],
maintainers: [ 'types <[email protected]>' ],
time:
{ modified: '2016-07-11T22:29:54.099Z',
created: '2016-05-17T18:45:34.270Z',
'2.0.13-alpha': '2016-05-17T18:45:34.270Z',
'2.0.14-alpha': '2016-05-19T22:10:45.225Z',
'2.0.19-alpha': '2016-05-20T20:32:35.406Z',
'2.0.20-alpha': '2016-05-25T05:48:27.231Z',
'2.0.21-alpha': '2016-07-01T20:25:22.182Z',
'2.0.22-alpha': '2016-07-01T23:48:33.623Z',
'2.0.23-alpha': '2016-07-02T03:19:31.235Z',
'2.0.24-alpha': '2016-07-04T01:10:42.331Z',
'2.0.25-alpha': '2016-07-08T21:15:41.038Z',
'2.0.26-alpha': '2016-07-11T22:29:54.099Z' },
author: 'Sergey Buturlakin <https://github.com/sergey-buturlakin>',
license: 'MIT',
readmeFilename: 'README.md',
repository:
{ type: 'git',
url: 'https://www.github.com/DefinitelyTyped/DefinitelyTyped.git' },
version: '2.0.26-alpha',
main: '',
scripts: {},
typings: 'index.d.ts',
dependencies: { '@types/react': '0.14.26-alpha' },
dist:
{ shasum: '1a8b9fc6e81b4722542c32c4a53b02cb8cad9e7c',
tarball: 'https://registry.npmjs.org/@types/react-router/-/react-router-2.0.26-alpha.tgz' },
directories: {} }
Running :
npm install @types\path-parsetest
I get:
npm WARN path-parsetest@1.0.0 No description
npm WARN path-parsetest@1.0.0 No repository field.
What is the plan (if any) for the typings
registry and typings already published as npm packages? Also the typed-typings
organization?
An example is the chai
typings package where DefinitelyTyped has version 3.4.0, but the typings
registry has the latest 3.5.0 ( https://github.com/typings/registry/blob/master/npm/chai.json )
README.md should list https://github.com/Microsoft/TypeScript as the place to log issues if a type definition is being published incorrectly
If the latest declaration file in DefinitelyTyped in the repo is 4, but a user needs to make updates to the v3 version of the package, then we need to show people how to do this correctly.
Otherwise resolution will fail on case-sensitive filesystems, as NPM enforces lower-cased package names.
This issue is exhibited in orchetrator's index, which contains the line:
/// <reference types="Q" />
and it must be
/// <reference types="q" />
Doing some initial testing with react and related packages; for example react-router:
npm i @types/react-router -- currently downloads from "tarball": "https://registry.npmjs.org/@types/react/-/react-0.14.21-alpha.tgz"
The index.d.ts file in the tgz -> tar package is not same as found in:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/types-2.0/react-router/react-router.d.ts
even when taking last update of May 25 into consideration.
When a definition is deleted from DefinitelyTyped, the publisher tool should issue a deprecation to NPM so people installing it still know it's been removed.
We should have the ability to say that a library bundles its own .d.ts file. This would generate a package that just depends on the underlying NPM package, and also generates an entry in the search index so we can surface at TypeSearch.
Right now we pessimistically assume that all past NPM publishes may have failed and query the NPM DB every time. This is slow and hinders fast incremental publish.
We should have two targets: incremental publish, and full publish. Incremental should assume that only 'new' versions need publishing, and full publish should do the full querying and republishing.
Also, only a full publish should fetch NPM package download counts.
npm install @types/node
The node v6 typings should be in index.d.ts in the node_modules/@types/node directory.
The node v4 typings are in index.d.ts in the node_modules/@types/node directory.
They will likely inevitably happen - like npm~atom
vs env~atom
. Is there a policy in place to figure out who takes what name in the @types namespace?
I brought this up before offline, but I want to post it here to discuss it thoroughly. The current implementation pins to major.minor
which blocks people from typing anything with a smaller version. This is a bit of an issue for anyone wanting to type/use pre-release software, or if something needs to be added for an actual patch release (though that breaks semantic versioning, not everyone follows it correctly - including TypeScript - and it could occur more likely on 0.x
versions where semver doesn't actually apply).
The way this is solved in Typings is by using the build metadata part of semver. Specifically, 2.0.0+timestamp
.
@RyanCavanaugh @andy-ms I know you mentioned you were doing some dev work on types-publisher and the DT-to-NPM pipeline. Have you put merge/pub fortypes-2.0 on hold for the time being?
If so, could you kindly provide expected timelines when merges resume? Otherwise, there are several simple, yet important PRs which could readily be merged, they have aged for a week now, without any comment or action.
Would appreciate, if they could be moved through. The DT PR numbers are listed below:
Thanks in advance for your attention to the matter.
The search index creation script gets NPM download counts, but this process is quite slow (several minutes) and the data doesn't change in an interesting way very often. We should cache this data locally so we can more quickly rebuild the search index with download numbers in them, and only update this cache ~weekly or so.
I was trying to get an Angular 1.x project working with TypeScript 2.0 using the @types/angular
typings. I kept on getting duplicate identifier errors in the .d.ts files, even when using the new skipLibCheck
option. What I finally discovered as I dug into it is that when you install the Angular types, you get a nested structure looking like this: node_modules/@types/angular/node_modules/@types/angular
Deleting the node_modules
folder under node_modules/@types/angular
resolved the errors.
Upon further inspection, I realized that the package.json
file created for the Angular typings had a package id of @types/[email protected]
and a dependency on "@types/angular": "1.5.4-alpha"
.
You can also see the dependency on the NPM page for the Angular typings: https://www.npmjs.com/package/@types/angular
Is there any way to prevent this from happening?
We should allow folder structures like this:
/jquery
index.d.ts
tsconfig.json
jquery-tests.ts
/v2
index.d.ts
tsconfig.json
jquery-v2-tests.ts
/v3.1
index.d.ts
tsconfig.json
jquery-v3.1-tests.ts
This should parse the major and optional minor version number from the folder name and generate versioned packages published under the same name as the parent folder.
I'm the primary contributor to the ng-table project.
I'm rewriting the source code to typescript using es2015 modules. As a consequence the new version of the library will include it's type declarations inside of the main ng-table npm package.
Once this new version of ng-table is published, this will make @types/ng-table only relevant for the old version of ng-table.
Can you advice how to ensure that consumers of the ng-table library will use the correct version of the type declarations?
For example should ng-table be included in https://github.com/DefinitelyTyped/DefinitelyTyped/blob/types-2.0/notNeededPackages.json
Thanks
Christian
If we want this to run on azure, we should avoid using child_process
and instead use APIs directly.
We should cache the result of the logIn
function in npm-client.ts
.
We could do this in a local file, but this could be a security issue.
Maybe we should delay this until we are using KeyVault.
I've got errors after @types/history
is installed:
node_modules/@types/history/index.d.ts(120,42): error TS2307: Cannot find module 'history/lib/createBrowserHistory'.
node_modules/@types/history/index.d.ts(121,46): error TS2307: Cannot find module 'history/lib/createHashHistory'.
node_modules/@types/history/index.d.ts(122,48): error TS2307: Cannot find module 'history/lib/createMemoryHistory'.
node_modules/@types/history/index.d.ts(123,43): error TS2307: Cannot find module 'history/lib/createLocation'.
node_modules/@types/history/index.d.ts(124,40): error TS2307: Cannot find module 'history/lib/useBasename'.
node_modules/@types/history/index.d.ts(125,44): error TS2307: Cannot find module 'history/lib/useBeforeUnload'.
node_modules/@types/history/index.d.ts(126,39): error TS2307: Cannot find module 'history/lib/useQueries'.
node_modules/@types/history/index.d.ts(127,26): error TS2307: Cannot find module 'history/lib/actions'.
Looks like lib
folder from DefinitelyTyped repository is not included into @types/history
module.
I pushed a change with a PR to the Definitely Typed repo yesterday, which was merged, yet the corresponding @types/node-schedule package on npm hasn't updated to reflect that.
Is that an expected behaviour, or am I supposed to do something else?
@RyanCavanaugh thanks for merging the two D3 related PRs yesterday on DT/types-2.0 !!!
When updating my Angular 2 service for D3, I noticed the following oddity related to the propagation to @types:
npm install
with all d3-***
module definitions, the correct latest definitions are pulled down from npm with correct version numbers. So the new version parsing works. Thanks @andy-ms ๐However, for the only following three definitions which were updated yesterday:
neither the README displayed on npmjs, nor the listed release number are reflective of the npm "latest" package. Again, the npm packages themselves are fine.
Started at Tue, 05 Apr 2016 21:00:52 GMT
Found 1704 typings folders in ../DefinitelyTyped
DataStream.js
should be strictly lowercaseFileSaver
should be strictly lowercaseFinch
should be strictly lowercaseHeadroom
should be strictly lowercaseHubSpot-pace
should be strictly lowercaseJSONStream
should be strictly lowercaseOpenJsCad
should be strictly lowercasePayPal-Cordova-Plugin
should be strictly lowercaseadal
is in folder with incorrect name adal-angular
amplify
is in folder with incorrect name amplifyjs
angular-localForage
should be strictly lowercaseprotractor
is in folder with incorrect name angular-protractor
angularLocalStorage
should be strictly lowercaseangularjs.d.ts
or index.d.ts
ngtoaster
is in folder with incorrect name angularjs-toaster
power-assert
is in folder with incorrect name assert
auth0-lock
is in folder with incorrect name auth0.lock
Auth0Widget
is in folder with incorrect name auth0.widget
WindowsAzure
is in folder with incorrect name azure-mobile-services-client
bingmaps.d.ts
or index.d.ts
bounce.js
is in folder with incorrect name bounce
business-rule-engine
is in folder with incorrect name business-rules-engine
chrome.debugger
is in folder with incorrect name chrome
cldr
is in folder with incorrect name cldr.js
dcjs.d.ts
or index.d.ts
deployJava
should be strictly lowercasedocCookies
should be strictly lowercaseegg
is in folder with incorrect name egg.js
eqjs
is in folder with incorrect name eq.js
fabric
is in folder with incorrect name fabricjs
FB
is in folder with incorrect name fbsdk
flexSlider
should be strictly lowercaseFoundation
is in folder with incorrect name foundation-sites
fullCalendar
should be strictly lowercasegapi.youtubeAnalytics
should be strictly lowercaseelectron
is in folder with incorrect name github-electron
go
is in folder with incorrect name goJS
goJS
should be strictly lowercasegoogle-apps-script.d.ts
or index.d.ts
grunt
is in folder with incorrect name gruntjs
gsap.d.ts
or index.d.ts
highlight.js
is in folder with incorrect name highlightjs
howler
is in folder with incorrect name howlerjs
i18n
is in folder with incorrect name i18n-node
interact
is in folder with incorrect name interactjs
ion.rangeSlider
should be strictly lowercaseis
is in folder with incorrect name is_js
ix.js.d.ts
or index.d.ts
joData
should be strictly lowercaseajaxfile
is in folder with incorrect name jquery.ajaxfile
autosize
is in folder with incorrect name jquery.autosize
jquery.blockUI
should be strictly lowercasejquery.clientSideLogging
should be strictly lowercasejquery.contextMenu
should be strictly lowercasejquery.customSelect
should be strictly lowercasejquery.dataTables
should be strictly lowercasejquery.leanModal
should be strictly lowercasejquery.notifyBar
should be strictly lowercasejquery.postMessage
should be strictly lowercasejquery.rowGrid
should be strictly lowercasejquery.scrollTo
should be strictly lowercasejquery.simplePagination
should be strictly lowercasesimplemodal
is in folder with incorrect name jquery.simplemodal
jquery.slimScroll
should be strictly lowercasejquery.sortElements
should be strictly lowercasejquery.superLink
should be strictly lowercasesignals
is in folder with incorrect name js-signals
knockout-amd-helpers
is in folder with incorrect name knockout.amd.helpers
leapmotionTS
should be strictly lowercaselocalForage
should be strictly lowercaself
is in folder with incorrect name lovefield
mCustomScrollbar
should be strictly lowercasebackbone.marionette
is in folder with incorrect name marionette
multiplex
is in folder with incorrect name multiplexjs
naturalSort
is in folder with incorrect name natural-sort
ng-cordova.d.ts
or index.d.ts
noVNC
should be strictly lowercaseazure
is in folder with incorrect name node-azure
ffi
is in folder with incorrect name node-ffi
git
is in folder with incorrect name node-git
imap
is in folder with incorrect name node-imap
nw.gui
is in folder with incorrect name node-webkit
zmq
is in folder with incorrect name node_zeromq
numeral
is in folder with incorrect name numeraljs
paralleljs
is in folder with incorrect name parallel
PDFJS
is in folder with incorrect name pdf
webpage
is in folder with incorrect name phantomjs
pouchDB
should be strictly lowercasepubsub-js
is in folder with incorrect name pubsubjs
raven-js
is in folder with incorrect name ravenjs
Raygun
is in folder with incorrect name raygun4js
react-bootstrap-daterangepicker.d.ts
or index.d.ts
module
is in folder with incorrect name requirejs
domReady
is in folder with incorrect name requirejs-domready
rx.jquery
is in folder with incorrect name rx-jquery
sammy
is in folder with incorrect name sammyjs
sencha_touch.d.ts
or index.d.ts
simpleStorage
is in folder with incorrect name simplestorage.js
SinonChrome.debugger
is in folder with incorrect name sinon-chrome
slickgrid.d.ts
or index.d.ts
sockjs
is in folder with incorrect name sockjs-node
Sortable
is in folder with incorrect name sortablejs
Squire
is in folder with incorrect name squirejs
Stamplay
is in folder with incorrect name stamplay-js-sdk
svg.js
is in folder with incorrect name svgjs
threejs.d.ts
or index.d.ts
tinycolor2
is in folder with incorrect name tinycolor
bloodhound
is in folder with incorrect name typeahead
angular-ui-grid
is in folder with incorrect name ui-grid
angular-ui-router-extras
is in folder with incorrect name ui-router-extras
vex
is in folder with incorrect name vex-js
webrtc.d.ts
or index.d.ts
Currently, it seems dependencies rely on some path trickery. This is a pain, because if a definition is ever moved inline you can not deprecate it. Typings resolves this by allowing type definition resolution over multiple sources, but DefinitelyTyped does not prescribe dependencies.
You might want to standardise on using package.json
internally with DefinitelyTyped to specify dependencies.
I'm looking forward to using the npm way of getting type definitions. Unfortunately the npms are missing the repository
metadata.
Unfortunately the build infrastructure that I use requires npms to contain this standard metadata.
So my request is for the repository
metadata to be available in @types npms.
Someone forgot to put in a year and owner in the LICENSE
Line 189: Copyright {yyyy} {name of copyright owner}
I'm having an issue with @types/react-redux I saw that there was a fix 3 days ago DefinitelyTyped/DefinitelyTyped@b488f3c
But on NPM the latest published was 2 weeks ago.
What can I do?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.