Import nonexistent module is not checked

[evmar]

TypeScript Version: playground

Code

import {a} from 'nosuchthing';  // error: Cannot find module

import 'othernonsense';  // no error, even with --noImplicitAny

Expected behavior:
Both of these should error. There should be a way to always get a compile-time error when you make a typo in an 'import' statement, regardless of which form you use.

Actual behavior:
No errors. I appreciate that it's intentional (in the implicit-any case) that modules lacking types are just treated as 'any', but that means in the case where you want to be more strict there's no way(?) to have TS check all module imports.

[RyanCavanaugh]

Duplicate #20534

[RyanCavanaugh]

Note that you can write

import {} from 'othernonsense';

once #20671 is merged

[evmar]

Dang, sorry for the noise, I really did try to search for dup.

[jamietre]

@RyanCavanaugh I'm confused. I posted #20534. You seem to be saying that we can use syntax import {} from 'something' as a workaround to ensure it will fail if something doesn't exist when importing no symbols, when this PR is merged.

According to the PR you reference, #20671 fixes a bug:

tsc should fail with an error "Cannot find module 'nothing'", just like what it does when we say
import 'nothing';
or
import {nothing} from 'nothing';
or
import * as nothing from 'nothing';

But you just told me in the issue I posted that not failing -- for the first syntax he describes -- "is the intended behavior as per many requests from users to support scenarios such as importing CSS modules"

Put another way: the pull request says *all these syntaxes should fail, and it's fixing a bug causing import {} ... to not fail."

You just told me in my bug report it's expected that the import 'something' syntax should not fail

Can you please clarify what is the expected behavior, and what it will be after this pull request is merged? It sounds like the author of the PR thinks that the syntax import 'something' will fail when something is not resolvable. However, obviously from my own issue and this one, that is not the case. So when this PR is merged, will the {} syntax fail, but the plain syntax not fail?

Again, I'm not sure why we'd want any of these to not fail, regardless of whether or not we choose to parse a module. But it seems that they should all be consistent; your comment here indicates that you think "{}" will be a workaround to the default behavior of not checking the module when importing no symbols, but clearly that's not what the author of the PR thinks (he thinks they should be consistent).

[mhegazy]

Please see my response in #20576 (comment)

[jamietre]

Why can't the *existence* of a file be checked without parsing it? Wouldn't people importing css or anything else still want a build failure if the module is missing?

…

On Jan 4, 2018 6:27 PM, "Mohamed Hegazy" ***@***.***> wrote: Please see my response in #20576 (comment) <#20576 (comment)> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20767 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAi-gMzHGNysAxUGOn34a4jkYCgIU9Ncks5tHV5SgaJpZM4RGIvM> .

[jamietre]

Sorry I see you did address that. What about simply making it a compiler option, with a regex to ignore or include certain files? I am sure there are many people who do this, but this is pretty glaring omission from a tool whose primary purpose is compiling code. It makes our build insecure.

…

On Jan 4, 2018 6:36 PM, "James Treworgy" ***@***.***> wrote: Why can't the *existence* of a file be checked without parsing it? Wouldn't people importing css or anything else still want a build failure if the module is missing? On Jan 4, 2018 6:27 PM, "Mohamed Hegazy" ***@***.***> wrote: > Please see my response in #20576 (comment) > <#20576 (comment)> > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#20767 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAi-gMzHGNysAxUGOn34a4jkYCgIU9Ncks5tHV5SgaJpZM4RGIvM> > . >

[mhegazy]

Why can't the existence of a file be checked without parsing it? Wouldn't
people importing css or anything else still want a build failure if the
module is missing?

it would. but that means the compiler needs to monitor mode files, and resolve more files, module resolution is an expensive operation, and ideally we would not have to do it.

it becomes more interesting when users have module loader extensions, e.g. requirejs: http://requirejs.org/docs/plugins.html (foo!something.css) vs. SystemJs plugins which have a diffrent name.

[jamietre]

One other thought:

While I understand why (some) people want this, ultimately importing javascript is actually a real, valid use of import, while importing CSS/webpack loaders/etc is a non-compliant overload.

Why not create a special directive people can use for the non-spec case, which is compiled to import if es6 or require if commonjs?

(I realize this would be a big breaking change - but again - a flag to opt in)

[mhegazy]

Why not create a special directive people can use for the non-spec case, which is compiled to import if es6 or require if commonjs?

We really do not want to add any new non-ES-complaint syntax. we only do it when we absolutely have to.

(I realize this would be a big breaking change - but again - a flag to opt in)

there is a cost for adding additional flags both in complexity and maintenance.

[jamietre]

I understand that it's a thing to be done. But isn't supporting the actual spec usage at least as important as supporting non-spec usage? Even a simple flag to enable/disable import-less imports would be of immense value. I think it's far more common these days to use webpack config to map extensions to loaders than to inline the config on imports. We use webpack too, and we'd really like import 'path/to/something.css' to be validated (as well as the occasional bootstrapping module). I guess this could be done with a post-build process, but what a lot of work to do something that the compiler is already designed to do.