Typescript: Add jsconfig.json option to resolve directory-named-webpack-plugin paths

[mjbvz]

_From @tylerkayser on May 14, 2018 20:30_

Issue Type: Feature Request

In our Webpack configuration, we use directory-named-webpack-plugin to remove redundant segments from our file pathing. i.e.

'components/Dropdown/Dropdown' becomes 'components/Dropdown'

It would be great if the IDE was able to understand this pathing and look for files named after their directory, rather than only looking exclusively for index.js files.

I propose adding an option within jsconfig.json to support this functionality.

VS Code version: Code 1.23.1 (d0182c3417d225529c6d5ad24b7572815d0de9ac, 2018-05-10T16:03:31.083Z)
OS version: Darwin x64 17.4.0

_Copied from original issue: Microsoft/vscode#49857_

[mhegazy]

you can add a path-mapping to your jsconfig to map these. See more at: https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping.

This will require a mapping for each module you use. I do not think we will be adding an option for treating directory name as module name since this is a very specialized use case.

[tylerkayser]

We already use path mapping for aliasing, so I know how effective it can be. However, in a large codebase, it's unrealistic to add mappings for every single directory in order to support this functionality.

If it were possible to add placeholders to path mappings, that could also solve this issue. Something like this might work:

"paths": {
  "*/$1": ["*/$1/$1"]
}

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

[gaui]

@mhegazy : I do not think we will be adding an option for treating directory name as module name since this is a very specialized use case

Not at all. When you are working with components you often put each one in a seperate folder and put assets tied to that component in the same folder, something like this:

|   +---Component1
|   |       Component1.css
|   |       Component1.tsx
|   |
|   +---Component2
|   |       Component2.css
|   |       Component2.tsx
|   |
|   \---Layout
|       |   Layout.css
|       |   Layout.tsx
|       |
|       \---Header
|       |       Header.tsx
|       |       Header.css

Today you have to import ./components/Component1/Component1 or create an index file that imports/exports the component so you can import ./components/Component1 instead, which results in importing the index (but it's implied). The first one is ugly and confusing, because you omit / and .tsx extension. The requirement for the index extra step is probably the main reason why this TC39 proposal exists.

Why wouldn't it make sense to try to resolve a file with the same name as the folder it's in? Something like this:

======== Resolving module '../components/Layout' from '/src/pages/Home.tsx'. ========
Loading module as file / folder, candidate module location '/components/Layout', target file type 'TypeScript'.
/components/Layout.ts' does not exist.
File '/components/Layout.tsx' does not exist.
File '/components/Layout.d.ts' does not exist.
File '/components/Layout/package.json' does not exist.
File '/components/Layout/index.ts' does not exist.
File '/components/Layout/index.tsx' does not exist.
File '/components/Layout/index.d.ts' does not exist.
File '/components/Layout/Layout.ts' does not exist.
File '/components/Layout/Layout.tsx' exist - use it as a name resolution result.

Second solution would be to add a placeholder to path mappings like @tylerkayser suggested. Something like:

"paths": {
      "*": [
        "*",
        "$1/*"
      ]
    }

Because of how web development landscape is today and the fact that this structure is getting more popular with component architecture and popular frameworks like React/Vue, I think you should consider reopening this issue.

[hyphen-wrex]

Is there any progress on this?

[rdsedmundo]

I really I’d like to see something similar from what was suggested as well. +1.

[shahzaibkhalid]

Is there any chance that this would be prioritized?

[nickiaconis]

I'm interested in seeing this happen as well. Having a bunch of index files open causes tab width bloat (since directory paths appear next to the filename when two or more files with the same name are opened) and in general makes it more difficult to find the file one's looking for.

As @tylerkayser states, using path mapping as it exists now is untenable for any project of meaningful size. It's not necessary that directory name resolution be included in the default resolution strategy, but having a reasonable way to alter the resolution strategy and achieve this seems like it'd be a win.

[marcel0ll]

Would it possible to add this functionality using an extension?

[Eylen]

Any hint on how could this be implemented in a custom extension?

[rdiazv]

Waiting for this 🙏

[amaisenovich]

@mhegazy

directory-named-webpack-plugin has up to 60k weekly downloads. This doesn't look like "a very specialized use case" (c) for me. Please, reconsider opening this issue.

[arnorhs]

it's possible they ignore all closed issues... maybe open a new one?

[matt-curtis]

It's pretty tragic there's been no movement here. @mhegazy any final word on this?

[sidouglas]

Absolutely! I'd love to see progress on this. The package.json main entry "hack" isn't feasible with Jest ( it complains ). Not everyone is using webpack.