Seeking community feedback on this plugin about resolve-typescript-plugin HOT 9 CLOSED

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.

from resolve-typescript-plugin.

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! 😄

from resolve-typescript-plugin.

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

from resolve-typescript-plugin.

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.

from resolve-typescript-plugin.

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

from resolve-typescript-plugin.

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

from resolve-typescript-plugin.

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

from resolve-typescript-plugin.

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

from resolve-typescript-plugin.

@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.

from resolve-typescript-plugin.