Feature request: Auto-include tsconfig-paths-webpack-plugin when typescript is enabled

[beorn]

• electron-builder@^22.9.1
• electron-webpack@^2.8.2:
• electron-webpack-js@~2.4.1:
• electron-webpack-ts@^4:

Would it make sense to include tsconfig-paths-webpack-plugin by default if typescript is enabled so that source aliases/ path mappings work out-of-the-box? I think it's kind-of a core feature of Typescript / tsconfig.json so it would be nice if it "just worked".

Currently you have to add this webpack config:

const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin')
module.exports = { resolve: { plugins: [new TsconfigPathsPlugin()] } }

[loopmode]

Not sure, I find this interesting but I'm sceptical 🙂

Currently, optional things work like this: electron-webpack checks your package.json for certain dependencies it knows about. When it finds one, it uses that package/feature/plugin.

In this case it would mean, if the user adds tsconfig-paths-webpack-plugin to devDependecies, it will be included automatically.

Default case solved, user saved two lines of config :)

However, you'll need to provide options in some way. You'd need a new config field, e.g. tsConfigPaths, and the user would provide it via configuration. Of course this means more ifs for the core library, as there is no generic system as of now. It really comes down to a bunch of user-requested ifs and elses :)

Then, we'd need to check whether it collides with existing alias features. For example what happens when user overrides some existing source aliases. Would there be duplicate keys, do we need to merge something, do we need to provide default options to that plugin to avoid problems etc.

Lastly, in real-world scenarios, you will use a custom webpack config in userland anyways. For the various reasons of the given project XY.

Currently you have to add this webpack config:

const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin')
module.exports = { resolve: { plugins: [new TsconfigPathsPlugin()] } }

Since it's that easy to use it, I don't think it's worth the increased complexity in the core library. Adding complexity to userland as well:

You would be managing various things in your webpack config, but this one would be.. spread across several other places.

There would be aliases in tsconfig, but plugin options in package.json or electron-webpack.config.js. And their combined effect would be on the webpack config. For which you actually do have a custom configuration file, but you can't manage the plugin options there, because some magic hides it 🙂 (You could iterate plugins in your webpack config module, to find the instance of this plugin, then mutate its options or remove it and place your own instance with your own options...)

So.. Not sure if there would be benefit in doing all that.

I'd love the aliases setup to be simpler and better. And I have to try out that plugin! However I don't think it's a good idea to include this "by default".

What do you think regarding those aspects?

Maybe it's much easier and I just don't see it :) Also maybe you can just check it out and provide a PR

[beorn]

I think the point is that most people want to stay on the "happy path", especially if they use something like electron-webpack (instead of a completely ejected setup), and expect tsconfig.json's path mapping to actually work as they do if you use tsc. I think this is relatively important to make the TypeScript experience a great one given the increasing popularity of TypeScript.

So what about supporting/optimizing for the straightforward case and warn the user that they are on their own if they stray away from the happy path?

tsconfig.json can either not have a paths (backwards compatible) or if it has a paths then it must/should include the path aliases that electron-webpack expects plus the user-configured ones (a superset). So the user doesn't have to worry about any other path configs - they have a typescript project and configure all paths as they would a typescript project.

1. For people that don't use tsconfig's paths it would just work like it does now
2. For people that do use tsconfig's paths those paths are used for the entire project (but an error/warning is issued if those paths are not a superset of the aliases electron-webpack expects)

That makes the tsconfig path config support discoverable, explicit, and "standard TypeScript", so it would also integrate well with the editor's language server (vscode etc). There's no need for any additional config options.

But I just realized one problem: the @ alias is different for the renderer and main targets, which is hard to support with just one tsconfig.json.

[loopmode]

Yeah but that @ is an issue that is unrelated to this. I mean, it's an issue with or without the automatic mapping. I have accepted that I can't use @ with typescript in two pet projects already and it's not that bad. And maybe it's just not that good a feature as it's quite ambiguous. I had this covered in my first response but then dropped it eventually.