rschristian
commented
2 years ago It's not intentional, no. Just an oversight!
If you're willing to implement this (I can otherwise take a look over the next couple days probably), it should be pretty simple (I believe. TS can quickly become a rabbit hole, so hopefully I'm not too naive for hoping this is simple).
rpt2 resolves a tsconfig.json against the current working dir. So what should happen is that when cwd != '.' and --tsconfig is undefined (default val), we should try to resolve a ​`${cwd}/tsconfig.json`​. If it exists, set options.tsconfig so it can be passed into the plugin here:
Edit: Missed part of your comment. I don't think we want to do --cwd a/b/c --tsconfig tsconfig.json where that tsconfig path is actually a/b/c/tsconfig.json. That seems like it'd be quite confusing. I think --tsconfig can keep it's normal pathing, but we should try to pick up on any tsconfig.json in that directory.
Admittedly it'd be a bit annoying if you had to do --cwd a/b/c --tsconfig a/b/c/something-tsconfig.json, but easier to understand what's happening, IMO.
Edit 2: (Forgot to press "post" on this) Turns out rpt2 has a cwd option that we can use instead. Whoops. I've somehow read over that 3-4 times now.
Very easy fix.
make-github-pseudonymous-again
Is it expected that
tsconfigresolves against the calling directory even when--cwdis specified? I have a use case where I have a browser lib and a node lib in the same repo that have distincttsconfig.jsonfiles. Currently I have to specify the full path to maketsconfig.jsondiscovery work, that is--cwd a/b/c --tsconfig a/b/c/tsconfig.jsoninstead of just--cwd a/b/c --tsconfig tsconfig.jsonor just--cwd a/b/c. Is there some other configuration that I do not know about that would make this more intuitive?