Skip to content
This repository has been archived by the owner on Jul 11, 2018. It is now read-only.

Wildcard module declaration hides all import errors #93

Closed
mirkonasato opened this issue Oct 13, 2016 · 9 comments
Closed

Wildcard module declaration hides all import errors #93

mirkonasato opened this issue Oct 13, 2016 · 9 comments
Assignees

Comments

@mirkonasato
Copy link

I was struggling to understand why an incorrect import statement in my code hadn't been highlighted by my editor (VS Code), when I finally noticed what's in declarations.d.ts.

I'm really not sure that's a good idea. I mean, I can write

import { Nothing } from 'nowhere';

and start using Nothing in my code thinking everything is fine since the editor shows no errors.

Then when I save the app nothing happens, and I need to look at the terminal running ionic serve to see there's a bundle dev update failed: Could not resolve ... error.

Not a very good developer experience. Is this "wildcard module" approach used by anybody else in the TypeScript community?

@danbucholtz
Copy link
Contributor

danbucholtz commented Oct 13, 2016

@mirkonasato,

I personally agree with you. I am not a huge fan. It really is pick your poison. We heard a lot of complaints from developers who don't like the typescript experience of needing types for third party libraries. We also have heard that using declare module 'xyz' is a pain too. So I'm not sure what to tell you 😄 . For now, just remove/comment the line and everything will be cool on your system. I'm not sure if we'll take action or not here.

If it were up to me and all developers were me, I'd want types for everything. Not everyone feels that way, though.

Thanks,
Dan

@mirkonasato
Copy link
Author

I don't actually have such a strong opinion on static vs dynamic typing, I can and have worked with both kind of languages.

What I do believe is that if you are using TypeScript then you're better off embracing it rather than trying to fight it.

@mlynch
Copy link
Contributor

mlynch commented Oct 13, 2016

Hey, so from what I can tell, TypeScript is going to soon fix the default failure case when an import doesn't have types. In the meantime, many Ionic devs were struggling with using 3rd party imports that don't have types and were not able to progress w/o understanding declare module.

We're in a bit of a bind until TS pushes an improvement for this, which I've heard will be in the next release. Right now we've weighed the downsides to doing declare module * vs explict types in modules and realized this is the path of less resistance right now.

If you understand the tradeoffs with using non-typed modules, then you can safely uncomment this. We prefer the defaults to be forgiving.

@jthoms1
Copy link
Contributor

jthoms1 commented Oct 13, 2016

This is the PR in the typescript repo to fix this issue. microsoft/TypeScript#11446

@mirkonasato
Copy link
Author

Interesting, thanks for the info. To be fair declaration files for third party libraries are TypeScript's main pain point.

Anyway, I still don't fully understand how that declare module '*' works in practice, I'll do some experiments.

@mirkonasato
Copy link
Author

Right, so basically thanks to the wildcard module people can install say lodash and import it as

import lodash from 'lodash';

without declaring it in a *.d.ts file first. But, if people were used to include lodash with

<script src="lodash.js"></script>

and then just use it as a global _ variable, then the new approach is still different and needs to be explained anyway.

While the downside is that if somebody types e.g.

import { Storage } from 'ionic-storage';

instead of @ionic/storage they won't see any error straight away telling them that there is no ionic-storage module.

Not sure it's a worthy tradeoff, but I guess you'll be able to tell based on how many complaints you get.

@mlynch
Copy link
Contributor

mlynch commented Oct 13, 2016

Yea, and with that issue linked above, it's not long that we'll have to make the tradeoff. For now I think it's worth it, hope to not have to do this in a few weeks.

@mirkonasato
Copy link
Author

@danbucholtz
Copy link
Contributor

danbucholtz commented Oct 15, 2016

That is a fair point @mirkonasato. I don't disagree with you. TS 2.1 is progressing well so we'll have this restored to an ideal state soon.

We're not going to take any action here for now. So I'm going to close this since we use issues as a backlog of things to work on.

Thanks,
Dan

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants