Ignore missing vendor definitions

Typescript is amazing. But when it comes to work with vendor libraries written in pure javascript it sucks. It sucks because afaik you have only one option: create a definition file for these vendors. And this is a bad option. Typescript says that "creating defintion files is easy". Yes it is, but it is only on surface. Why it is not easy:

you need to cover all api of the vendor library, otherwise its meaningless. But its complicated and not always possible because of related issues
vendor should have a good api documentation for all its methods, which is not always true, and when its not true you either create definitions with half of the avalible methods, either your definition file will be confusing. creating definition files from vendor sources almost impossible
it takes lot of my time that I dont have, and my product dont have it as well

And Dont tell me about DefinitelyTyped.org because you never find "high quality" definition files from there when you want. in all other times you'll find that DefinitelyTyped definitions are outdated - vendor api is changed and you cant use it with outdated definition files.

Some of my friends (very good and expirienced developers) who tried to use typescript stopped to use it only because of these issues. People dont have time to create and mainitan defintion files.
This is really anonying when you are building your project.

When angular2 will come stable, millions of people gonna use it, but how do they react that they cant use millions of vendor libraries and plugins that exist. This is really anonying when you are building your project.

Personally Im using typescript with nodejs and lot of node modules Im using also needs in defintion files.

I think one of the solution to this problem is to add a compiler feature of ignoring missing vendor definitions. Probably it can be done with configuration files. Something like this:

{
     "ignoreDefinitions": [ "somelib" ]
}

import * as somelib from 'somelib';
somelib.someOfItsMethod(); // here typescript will not give any errors, just will treat that somelib is *any* and contains *anies*

Yes, its not typesafe, but it will make Typescript more user-friendly, and make it more as an amazing addition to javascript, instead of being something isolated with its own annoing rules and restrictions of using (like dart and coffescripts are. for the same reason their concept isnt as best and good-fit for community and people, as typescript is)

If this solution is not acceptable, then Typescript team should figure out something else, better. The goal is to make typescript more user-friendly, product-friendly and integrate typescript into community of javascript world.

This is a community problem and not a technical problem. I think a better way to tackle this problem is to encourage people to submit declarations not to TSD, but to repo owners directly. I have also seen many repos being outdated and not even being present at TSD. TSD is not a good option in my mind. So current strategy of encouraging people to use TSD is not an effective strategy.

Also submitting PR:s to JS repo owners will effectively encourage people to write in TS, because I think many people will like me discover it being much more powerful than JS.

You can write "vendor definition" this way:

declare var $: any;
declare var ko: any;
declare var somelib: any;
// etc...

Looks like the original issue has been answered. please reactivate if you are running into other issues.

Mohamed Hegazy (@mhegazy)

Mohamed Hegazy (@mhegazy),

This problem has not been solved, IMHO. I'm working on a new TypeScript project, and already there are 13 modules that do not have definitions available.

This means that I have to maintain a definitions file (I call it typings.d.ts) with temporary declarations like this:

declare module "gulp-print" {
    var gulpPrint: any;
    export = gulpPrint;
}

This is not elegant, and this is not a community problem as previously suggested – there will always be cases where definitions are not available, and while I would like to write some and contribute back to the community, this is a low-priority task and I'm unlikely to find the time to write 13 high-quality definitions (not to mention the maintenance).

Because of this, I would really appreciate a mechanism for temporarily ignoring Cannot find module 'x' errors.

Here are some of the options:

import foo: any from "foo"; – the method mentioned by yourself in Importing files other than TS modules #2709. One downside, as mentioned by another user, is that when type definitions become available for module "foo", you will have to update your code (most-likely in multiple places).
A compiler option to implicitly assign type any to modules lacking definitions, as suggested by David Faivre (@dfaivre), also in Importing files other than TS modules #2709. When definitions become available, they are used without requiring any changes to the code.
A compiler option to explicitly list modules to temporarily ignore, as suggested by the OP. When definitions become available, you will need to update tsconfig.json (or the arguments to tsc).

Option 2 is probably ideal, but I might be missing something.

Please consider re-opening this issue (or pointing me to an existing, open issue).

Thanks. =)

option 1 is covered by #2709. option 3 is similar, IMO, to declare module "..." { export = any }, except that it is in code instead of configuration. for option 2, suppressing the error generally would not be a good idea, as you are throwing the baby with the bath water, and ignoring all errors because of handful of missing modules.

Hmm, you're right about option 2.

I don't like option 1 because it means that a bunch of files have to be updated when definitions become available.

WRT option 3, has something like this been considered? It seems a bit more elegant than this type of thing (which I am currently using).

Tried TypeScript for the first time tonight. Had some code switched over and webpack builds setup.

Really loved the idea of typescript and being able to incrementally add type safety to my code.

I'd expect TypeScript to make handling third party plugins straight forward. Hopefully give ways to ignore them. So, I googled for hours. Everything was either out of date for TypeScript 2 or wasn't detected, didn't work, etc.

I got stopped dead in the tracks due to third party plugins. While stuff in DefinitelyTyped worked like a charm, the difficulty setting up custom typings and why you can't just ignore non-typed plugins takes the value away.

As for custom typings and jQuery extensions, none of the solutions I researched via Google worked. The time I'd have to invest isn't worth what I'd get out of it at this point.

This is the same headaches I inevitably face with stuff like mypy. Great idea, would be helpful and reassuring to have, but when type definitions are missing, the headaches make me have to reverse the conversion.

why you can't just ignore non-typed plugins takes the value away.

you do not have to type things unless you want to.. not sure what is the issue you are running into.

As for custom typings and jQuery extensions, none of the solutions I researched via Google worked. The time I'd have to invest isn't worth what I'd get out of it at this point.

again, do not know what solutions you tried, and what worked/did not work for you. please consider filing a new issue, and giving us some context on what is not working.

I'm trying this from a js lib:
import MirageServer, { Factory } from 'mirage-server';

How do I defeat this error:

./src/index.tsx
(10,39): error TS7016: Could not find a declaration file for module 'mirage-server'. '/Users/nikos/WebstormProjects/client/node_modules/mirage-server/lib/index.js' implicitly has an 'any' type.
  Try `npm install @types/mirage-server` if it exists or add a new declaration (.d.ts) file containing `declare module 'mirage-server';`

the types don't exist btw

Wojciech Gebczyk (@wgebczyk)

Wojciech Gebczyk (@wgebczyk) you saved my ass bro, thanks a lot :D

Navigation Menu

Repository navigation

Ignore missing vendor definitions #3691

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Ignore missing vendor definitions #3691

Description

Activity

tinganho commented on Jul 1, 2015

wgebczyk commented on Jul 1, 2015

mhegazy commented on Aug 10, 2015

glen-84 commented on Dec 26, 2015

mhegazy commented on Jan 4, 2016

glen-84 commented on Jan 6, 2016

tony commented on Oct 31, 2017

mhegazy commented on Oct 31, 2017

quantuminformation commented on Dec 11, 2017

bellalMohamed commented on Jan 31, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions