Closed
Description
resolveFromOutDir
to Support External Build Orchestrators
- Let's assume "debug" build and "release" build
src/
├── foo
├── bar
└── baz
debug/
├── foo
├── bar
└── baz
release/
├── foo
├── bar
└── baz
-
You can build
foo
, and it knows its own output directory; but when it goes to import frombar
, it looks insrc/bar
instead ofdebug/bar
- Instead, we could have a flag that tells TypeScript "resolve relative to the output directory".
-
Feels like... maybe should have always been the behavior?
- There are some subtle issues - possibly around if your input directory is also your output directory.
-
Should we enforce that
outDir
is set and disjoint from the input files?- Seems like an overreach, there's a possibly useful configuration here.
-
Back to this example
projects/ ├── foo/ │ ├── src │ ├── win-out │ ├── mac-out │ └── linux-out ├── bar/ │ ├── src │ ├── win-out │ ├── mac-out │ └── linux-out └── baz/ ├── src ├── win-out ├── mac-out └── linux-out
- This wouldn't work under any configuration, right? Unless you have some weird hooks in place.
-
Weren't we exploring something more ambitious with parameterized project references?
- Yes, this seems to have more appetite though.
-
Any concerns around editor scenarios?
- Perhaps, if
foo
relies onbar
, ifbar
isn't built you'll get squiggles. - But this is using project references where we'll jump back to the correct source.
- Is it?
- Perhaps, if
-
How do other people use Bazel with TS?
- Certain companies that use Bazel/Blaze dynamically grow out the file list as needed with a customized tsserver driver.
- So stuff is possible! But we've never used it and don't have a good feel for it.
- Certain companies that use Bazel/Blaze dynamically grow out the file list as needed with a customized tsserver driver.
-
Conclusion: would be willing to take a PR for at least an MVP of the feature so we know we're shipping something that works for Bazel users.