Go to Definition for Non JS/TS File Imports

From microsoft/vscode#24276

Issue
Users of tools such as webpack often load non js/ts assets, such as css or images, using require or import:

require('./main.css');
import './image.png'
...

Operations such as go to definition currently do not work on these paths

Proposal
go to definition on these resource paths should try to open the corresponding resource in the editor.

They're a couple of great VS Code plugins that do this at the moment.
I assume they work by returning a "definition" that maps to a file and that VS Code then seems adds this as a possible definition to navigate to (I don't really know if this is how it works, but this is how it appears).

Because of this, they suffer from the following problem:

Say I have a declaration file, let's call it ambiance.d.ts with the following content

declare module '*.css' { export default '' as string; }
declare module '*.scss' { export default '' as string; }
declare module '*.html' { export default '' as string; }

in this case, despite of the plugins efforts, the user always sees a list of two definitions to go to instead of being able to jump directly to the file.

That is really the only drawback to the current plugins.

Having said that, I always thought it would be nice if TypeScript could validate the existence of these asset files but i think that ship has long ago sailed.

My main concern is that this is not ES6 compliant. ES6 does not talk about importing non-code modules. So this code is not really valid ES6 and will not work with a native ES6 module implementation.

So we can pretend that it will work, and just let it pass. or leave it the way it is and be spec-compliant.

I'm OK with not including this as builtin TS functionality given the compliance concerns. Is there any way we can leverage TSServer for these scenarios however? Perhaps with a TSServer plugin?

This is part of the module resolution logic, so we have to add it in the core.

Since this is specific to Webpack's implementation of require(), I would argue that it should go in @types/webpack-env, not core TypeScript. Isn't that how this is supposed to work?

James Bromwell (@thw0rted)

James Bromwell (@thw0rted) how is this specific to Webpack?

I should have said, since it's specific to the loader / bundler's implementation of require(). I was under the impression that TS didn't provide a native capability to require text resources, but maybe I misunderstood.

James Bromwell (@thw0rted)

James Bromwell (@thw0rted)

I should have said, since it's specific to the loader / bundler's implementation of require(). I was under the impression that TS didn't provide a native capability to require text resources, but maybe I misunderstood.

It is correct that TypeScript does not provide this capability, but Webpack is just one of many tools that do.

I think my point stands, in that case -- nothing in core TypeScript provides for require("foo.png") (or css or html or whatever) so it shouldn't be in an ambient declaration unless I've specifically added typings for an environment that does provide that ability. Right?

Yes you are quite correct. I didn't mean to suggest otherwise I was just mentioning that the notion is more general than Webpack.

Additionally TypeScript should be checking the path of EVERY import that occurs (module or otherwise) and raise an appropriate error. A hacky workaround silences an error that an html file isn't a module, but an incorrect relative path doesn't re-flag an error. So I'm stuck guessing that my import paths are hopefully correct.

microsoft/vscode#48025 (comment)

I don't get the argument regarding strict ES6 spec compliance. This is something webpack, fusebox and pretty much every bundler out there allows and encourages. I'd imagine this has plenty of devs out there using it. Widespread real-world use cases matter, so the meaning of what is and isn't 'compliant' needs to be re-evaluated in this case.

Besides if this needs to be supported by the core, and maybe just have an appropriate .tsconfig flag turned off by default, why not just do it?

I had read this issue earlier today, before I filed issue 90155 in vscode . This does not appear to me to address my problem.

But if, as you said earlier in this thread, there are extensions that workaround this I'd sure like to know of one. I've been scouring the extensions gallery trying to find it.

Do you know any by name that I could try?

I found a vscode plugin called file peek to provide this functionality. Hope also can help you guys.

Matt Bierner (@mjbvz)

When can we deal with this problem？Matt Bierner (@mjbvz)

It is very important to autocomplete files other than JS or TS and check the existence of a file. Due to its absence, typos often appear and, in general, work becomes less comfortable. Please make this opportunity.

Bump. It would be nice to have a way to do file path resolution with wild cards and extrapolate the beginning path and resolve the file using node.

declare module '*.css?raw' {
  const content: { [className: string]: string }
  file = require('[filepath].css')

  export default content
  return file
}

The above would both declare the typing and return the file it should be resolving. Of course there would need to be escape hatches for bad paths etc.

In the meantine, use can leverage CSS Navigation extension className resolution.

It planned to support import resolution in a future release.

I think this can be closed since this landed in TS 4.3 https://devblogs.microsoft.com/typescript/announcing-typescript-4-3/#go-to-def-non-js

I think this can be closed since this landed in TS 4.3 https://devblogs.microsoft.com/typescript/announcing-typescript-4-3/#go-to-def-non-js

Yep. I've just rechecked. Looks lite it works now

Yes, go to definition works. But how can I get rid of the warning "Cannot find module '../img/bla.png' or its corresponding type declarations.ts(2307)" while preserving this feature?

If I declare module '*.png' in global.d.ts the warning disappears, but then I'm again unable to use go-to-definition.

Gregor Dschung (@chkpnt)

Gregor Dschung (@chkpnt) A workaround; not too good but it works
declare module '*.png' { export default '' as any; }

Removes the warning and also go-to-definition

Unfortunately, adding { export default '' as any; } doesn't help. When I use go-to-definition, I end up in global.d.ts (which might be right, as there is the definition), but I want to open the file I'm importing. 🤷‍♂️

Here's an extension that implements the requested feature:
https://marketplace.visualstudio.com/items?itemName=thisismanta.third-eye

Here's an extension that implements the requested feature: https://marketplace.visualstudio.com/items?itemName=thisismanta.third-eye

It’s not solving the '.scss' navigation to file and style class.
Issue still exist.

I think this can be closed since this landed in TS 4.3 devblogs.microsoft.com/typescript/announcing-typescript-4-3#go-to-def-non-js

This seems to work for relative paths (import "./file.scss") but not for node_modules imports:

import "bootstrap-daterangepicker/daterangepicker.css";
import "primeicons/primeicons.css";
import "@my-monorepo/my-lib/stylesheet.scss";

With universal(ish) support for real ESM, do a lot of folks still use these fake resource import / require statements that only work in bundlers? Seems to me that if the bundlers want to let you inject a resource inline, they should come up with a new keyword instead of overloading one that your runtime understands. (Or, y'know, just get the resource with fetch or fs.read*)

Navigation Menu

Repository navigation

Go to Definition for Non JS/TS File Imports #15146

15 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Go to Definition for Non JS/TS File Imports #15146

Description

Activity

aluanhaddad commented on Apr 12, 2017

mhegazy commented on Apr 19, 2017

mjbvz commented on Apr 19, 2017

mhegazy commented on Apr 19, 2017

thw0rted commented on Aug 3, 2017

aluanhaddad commented on Aug 6, 2017

thw0rted commented on Aug 6, 2017

aluanhaddad commented on Aug 7, 2017

thw0rted commented on Aug 7, 2017

aluanhaddad commented on Aug 7, 2017

jpike88 commented on Apr 19, 2018

15 remaining items

joshglenn commented on Feb 7, 2020

DMQ commented on Mar 13, 2020

Cpanmac commented on Apr 17, 2020

mishannn commented on Aug 19, 2020

FrederickEngelhardt commented on Nov 2, 2020

edouard-lopez commented on Mar 12, 2021

dummdidumm commented on Jul 10, 2021

Yegorich555 commented on Jul 12, 2021

chkpnt commented on Sep 16, 2021

NerdPraise commented on Feb 1, 2022

chkpnt commented on Feb 8, 2022

aleclarson commented on Jun 6, 2024

shankarThiyagaraajan commented on Jun 23, 2024

fregante commented on Oct 4, 2025

thw0rted commented on Oct 4, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions