Closed kettanaito closed 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));
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
).
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?
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 🤔
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?)
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.
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.
This package can expose a CLI command to generate a standalone
tsconfig.alias.json
partial TypeScript configuration file based on the aliases inalias.config.js
. Once generated, you extend that partial configuration in yourtsconfig.json
to enable path alias: