Resolve file with same name as folder as index

[CaptainN]

Suggestion

🔍 Search Terms

Filename matches containing directory (folder), resolves index (default) for directory

default filename match parent folder directory in addition to index

✅ Viability Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals (suits 10, and 11 well).

⭐ Suggestion

Use the containing folder name as the index.tsx (for example, MyComponent/MyComponent.tsx) in addition to index.tsx (or index.ts), to improve IDE experiences, especially in VS Code.

📃 Motivating Example

It'd be great to be able to see the context provided by non-generic filenames in tab names, open files panel, and the search results panel, instead of a sea of index.ts[x] files, or be able to quickly open a module or component file by file name with the cmd+p menu in VS Code or other editors. VS Code does add a bit of context, but this gets quickly obscured when many files are opened, especially on laptop screens.

There are also issues with debugging/logging with sourcemaps in Chrome/Firefox/whatever, where all output or break point comes from index.ts[x] and browsers do a far WORSE job of providing additional context than does VS Code.

💻 Use Cases

When working with large projects, intended for compilation rather than use in node.js (source code projects), such as any large React component project, with css modules, storybook files, tests, etc., files tend to be grouped by component or module name, with the main file getting called index.ts[x]. This may even be lovely in node.js based apps, and a compilation step could be used to rename those files to index.js for node js.

The shortcomings of the current approach are simply that in a deeply nested module organization of source code, every file ends up with the same name - index - which doesn't provide enough meaning in an editor environment.

The only workaround I use now is to rely on the existence of an adjacent file (like MyComponent.module.scss) to open, and fine the file next to it, but this is not a great workaround for the search panel - in that case, I have to simply make my search results super wide, to find that context, where a filename that matched the component directory name would make things much clearer.

There is a webpack plugin for .js projects, but I'm not aware of anything compatible with TypeScript, and it'd be great if we had this as a default, well supported option. My team prefers (and I entirely agree) to stick with idiomatic patterns. Adding this to typescript proper would help make it an idiomatic option for typescript projects.

Technical note

This would basically add extra steps to module resolution:

1. /root/src/moduleB.ts
2. /root/src/moduleB.tsx
3. /root/src/moduleB.d.ts
4. /root/src/moduleB/package.json (if it specifies a "types" property)
5. /root/src/moduleB/index.ts
6. /root/src/moduleB/index.tsx
7. /root/src/moduleB/index.d.ts
8. /root/src/moduleB/index.ts
9. /root/src/moduleB/index.tsx
10. /root/src/moduleB/index.d.ts
** New Steps
11. /root/src/moduleB/moduleB.ts
12. /root/src/moduleB/moduleB.tsx
13. /root/src/moduleB/moduleB.d.ts

An example image of search results with many index.tsx files (this is from a non-webpack js project we are starting to convert to ts[x], but it shows the same issue):

This shows the tabs - note how much space is wasted (fewer tabs can be shown at once):

Open Editors:

[fatcerberus]

Is there any environment where this works at runtime? TypeScript's module resolution is specifically designed to work exactly how it would at runtime, so the compiler can leave your directory structure and filenames alone.

[RyanCavanaugh]

We generally don't add new naming conventions without some more technical motivation than this. It seems like this is really an editor / dev tool problem -- VS Code could be collapsing these more aggressively. I don't think there's any room for TS to improve the experience, nor that seeing foo/foo.ts everywhere is really that much of an improvement.

[CaptainN]

I don't know if any runtimes support it (I'm not even sure if node.js supports index by default using ESM imports), but I do know, my use of Typescript for browser based output is never designed to be resolved at runtime. It's always bundled. In that sense, it doesn't work like you've suggested either - in both cases, the module files have to be moved or transformed in some way.

I guess this is something of a friction. Source code is often organized in other platforms the way I've requested here, due to the reasons I've laid out. Why let dogma override pragmatism? I've laid out some pretty clear pragmatic issue when it comes to editing large typescript based projects.

It does look like the ESM resolution algorithms are grouped in to different named modes. For example, the mode that gets you index.js is called "node" - maybe there should be a "browser" mode.

[CaptainN]

It'd be an improvement, because it wouldn't need to show the directory at all - it would just show foo.ts. This problem is more obvious during debugging in Chrome or Firefox. It's not just an editor problem.

[MartinJohns]

Why let dogma override pragmatism?

This goes the other way too. You could just give your files proper names. Sure, the import will be slightly longer, but it's a pragmatic solution to your issue.

[CaptainN]

You could just give your files proper names.

Yeah, that's a possibility too. But it's kind of normal for source code to do what I'm describing, and also, it's weird to use index in compiled projects like these. It makes sense on servers (node.js), and for nextjs's routing system. But it's weird in source code.

Anyway, I made my unconvincing case.

[RyanCavanaugh]

Context for why we moved this: While we don't have any intention of changing module resolution, we agreed that the display of filenames like this in the UI could be much better in a lot of cases. The screenshots from the left-side bar show how bad the current UX is in cases like these. We didn't have any immediate home-run solutions but wanted to brainstorm a bit on how to make filename display always be contextually meaningful.

[CaptainN]

Just a reminder - this is also an issue in the debugger/console output, in both VSCode and in Chrome/Firefox/etc.

[mjbvz]

This also effects languages like python, where you can have a lot of __init__.py files

Assigning a few other people from the VS Code side who may be interested: @JacksonKearl for label and search, @TylerLeonhardt for quick open

[TylerLeonhardt]

Somewhat related to this problem https://github.com/microsoft/vscode/issues/72514

[TylerLeonhardt]

Added Andrea who owns search now and Logan who owns open editors (I think?).

[lramos15]

@TylerLeonhardt A large feature request I have is https://github.com/microsoft/vscode/issues/41909 which is similar in nature but only for the tabs themselves. This seems a bit more complex.

[mariusrak]

Hi, there is a directory-named-webpack-plugin and allowing vscode to understand this pattern would really make life easier. Because, as it was said multiple times, you don't really want numerous index.js files in your project. They doesn't make sense.