Seeking community feedback on this plugin

[djcsdy]

This plugin works by inserting itself into the resolution process, and whenever webpack is resolving a file ending in .js, the plugin tries .ts and then .tsx first, and then continues with the usual process if those files don't exist. This plugin ignores files within node_modules so those files are resolved as normal with no alteration to the file extension.

I'm not sure of my approach and I'm seeking community feedback, so if anyone interested in this problem could take a look and let me know what they think I'd really appreciate it.

In particular:

• Should this solution, or something like it, be rolled into another project such as ts-loader, enhanced-resolve, or webpack itself? I'm interested in helping with this if so. Opinions of the maintainers of those projects are especially welcome :-).
• Am I hooking into enhanced-resolve in the right place? There are lots of places I could hook in to do this and it's not clear if the one I've chosen is the best choice.
• Is there a better way to skip files from external libraries (e.g. files from node_modules)? At the moment the plugin skips over any request where node_modules appears as a part of the path, but I'm not really happy with this. Apart from being a hack, the current solution has the obvious problem that it doesn't work if external libraries are in a directory other than node_modules, and it doesn't work if the project you're building is itself in a node_modules hierarchy (I can imagine use cases for doing this). Ideally I think I'd like to ignore any request that has passed through ModulesInHierachicDirectoriesPlugin at any point, but I can't see a good way to do this.
• Is skipping imports from external libraries even a good idea? My rationale for skipping external files is that some library developers might distribute .ts files on npm in addition to the compiled .js files, for use with source maps, and it's desirable for webpack to resolve the .js files and not the .ts files in this case. TypeScript itself won't compile source files resolved from node_modules when you compile with tsc.

[jacobmischka]

I'm not knowledgeable enough about resolvers to speak to the second item, and while it would be nice to have built into common configs using ts-loader or babel-loader with the typescript plugin, I think it's fine having it in a separate plugin as long as it's visible and documented somewhere.

As for the other items, I am currently using a private dependency that currently intentionally publishes .ts files, which by default isn't handled by this plugin (as noted in items 3 and 4 in your comment above). My current quick hack so I could get something built yesterday evening was to just delete the node_modules check, which worked fine. So I think it would be great if there were a way to opt into dependencies being resolved using this plugin as well, whether by default (which didn't seem to cause any significant build time increases) or via an option.

TypeScript itself won't compile source files resolved from node_modules when you compile with tsc.

I believe it will if you tell it to in tsconfig.json, right?

I plan on putting something together and submitting a PR to opt out of the node_modules check entirely this weekend hopefully.

Thanks for putting this plugin together! It saved me from an annoying headache at 5:30pm on a Friday before a long holiday weekend! 😄

[djcsdy]

I'm glad this helped you!

I believe it will if you tell it to in tsconfig.json, right?

Good point, I'm wondering if the plugin should read tsconfig.json to decide what to compile. That wouldn't be too difficult to do because the TypeScript compiler exposes an API for this.

[djcsdy]

Pinging microsoft/TypeScript#16577 in the hope that people who need this plugin will see it.

[lifeiscontent]

@djcsdy does this plugin work with webpack 4 as well?

[lifeiscontent]

trying to get it implemented here: storybookjs/storybook#15973

[djcsdy]

@djcsdy does this plugin work with webpack 4 as well?

@lifeiscontent it should do, although I haven't tested it. If not please file a bug.

[vinothvk]

thanks for your work on this plugin. it helped me in my storybook webpack setup

[MTobisch]

I would also like to leave a word of thanks here. I can't believe the behaviour that this plugin adds isn't provided by default in webpack as it seems like such a common problem to me. Though the automagical .js-import logic of the TypeScript compiler seems like the root culprit. Why not just allow .ts-imports and compile them to .js-imports along with everything else?

In my use case, I've been using TypeORM which provides both a programmatic interface as well as a CLI to interact with the ORM/database entities. Both use the same files and as my project is bundled with webpack, they are incompatible with each other.

The CLI runs on (ts-)node which expects ESM compatibility with full file extensions in imports while webpack explodes when trying to find TypeScript files as .js-imports. Meanwhile, webpack could technically handle .ts-imports, but then the TypeScript compiler/intellisense complains that it can't make sense of it.

Its like trying to please three divas at once and one is always complaining no matter what.

I've found that you can workaround it by either adding // @ts-ignore above the .ts-imports to please the TypeScript compiler (at least when used with ts-loader) or making the CLI run with --experimental-specifier-resolution=node when not specifying file extensions, but you plugin seems a lot more elegant.

[djcsdy]

This functionality is now built in to webpack, see https://github.com/softwareventures/resolve-typescript-plugin#obsolete