open-draft / dotalias

A single configuration for path aliases to reuse across all your tools (TypeScript, Jest, webpack, Rollup, etc.).
91 stars 2 forks source link

Support TypeScript #1

Closed kettanaito closed 3 years ago

kettanaito commented 3 years ago

This package can expose a CLI command to generate a standalone tsconfig.alias.json partial TypeScript configuration file based on the aliases in alias.config.js. Once generated, you extend that partial configuration in your tsconfig.json to enable path alias:

$ npx dotalias ts
# "tsconfig.alias.json" successfully generated!
{
  "extends": "./tsconfig.alias.json"
}
smeijer commented 3 years ago

As we can only extend a single other config file, I don't know how useful that would be. It's nice to have, but not enough to support all cases.

I was more thinking about patching the tsconfig.json in the root of the users' project.

So: npx dotalias ts would do something like:

// pseudo
const alias = loadDotAlias();
const tsconfig = JSON.parse(fs.readFileSync('./tsconfig.json'));
tsconfig.path = alias.toTypeScriptPath();
fs.writeFileSync(JSON.stringify(tsconfig, null, 2));
kettanaito commented 3 years ago

What benefit do you see for patching the tsconfig.json directly? It looks like the only difference between patching it and extending a generated configuration is the addition of a new artifact config (tsconfig.alias.json).

smeijer commented 3 years ago

I do understand your concern for writing to a file that the library doesn't own (tweet), but the thing with extending is that it can only be done once.

Imagine the scenario that I have a project tsconfig.json file, that extends another "company/organization" json. Unless I'm missing something, I won't have the option to also extend tsconfig.alias.json, because a tsconfig can only extend a single file?

Or should my tsconfig.alias.json then extend my tsconfig.json (which extends "org.tsconfig.json"), and make the compiler use tsconfig.alias.json instead?

kettanaito commented 3 years ago

Yeah, that's a valid concern. I'd much prefer your config to extend tsconfig.alias.json than the other way around.

We can start with modifying the tsconfig.json directly and see how that feels when using the package. I wonder if there's a way to automate npx dotalias ts so you don't have to manually keep the alias in sync 🤔

smeijer commented 3 years ago

I do see some options.

The end user could add that command to pretest or prebuild npm script hooks.

We could also aggressively update when dotalias() is called, which happens for example if they also use it for jest. But that should be configurable trough an option in the config file.

Another solution for them, is to add it to a precommit hook, using something like husky.

And last option, they could do an import on a entry code file, to force synchronization.

import 'dotalias/sync' 

(can that be done by using tsconfig include?)

kettanaito commented 3 years ago

I like the last option the most: it's explicit, it's clear, and it should work. I wouldn't force implicit updates, not I think it's useful to keep an option for this in the configuration file. Such an option would only be used to opt-out, which is much easier if your setup is explicit in the first place.

can that be done by using tsconfig include?

Not sure. Afaik, include only affects what files are visible to the compiler, it doesn't really import them in any way. You may include a module, but if you never import it anywhere it won't get called.

kettanaito commented 3 years ago

I've added a basic TypeScript support. I see no need in introducing a sync script, as you are likely to sync configs on some Git hook, where it's much easier to call the npx dotalias ts instead of importing modules and executing them.