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:
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.
@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 #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).any
to modules lacking definitions, as suggested by @dfaivre, also in #2709. When definitions become available, they are used without requiring any changes to the code.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
@wgebczyk you saved my ass bro, thanks a lot :D
Most helpful comment
@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:
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 #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).any
to modules lacking definitions, as suggested by @dfaivre, also in #2709. When definitions become available, they are used without requiring any changes to the code.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. =)