microsoft/TypeScript

Design Meeting Notes, 2/25/2022

DanielRosenwasser opened this issue · 3 comments

resolveFromOutDir to Support External Build Orchestrators

#37378 (comment)

  • 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 from bar, it looks in src/bar instead of debug/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 on bar, if bar isn't built you'll get squiggles.
    • But this is using project references where we'll jump back to the correct source.
      • Is it?
  • 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.
  • 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.

Just to clarify

  • But this is using project references where we'll jump back to the correct source.
    • Is it?

I think this was a point of misunderstanding in the meeting - you've said (a few times) that you won't necessarily have project references set up - how do you anticipate the editor scenarios working?

There's nothing about Bazel that constrains users choices in this regard. In theory you configure it to run whatever tsc command-lines you want.
Even our ts_project "rule" gives users quite a bit of latitude about how to invoke tsc - it is mostly concerned with predicting what outputs will be created given the variety of compilerOptions that affect it, for example --declaration means to expect .d.ts file for each .ts input. But the semantics of defining different "compilation units" is loose.

One option for editors is to open the monorepo root, and the TS language service resolves first-party imports directly to the .ts source file, either by a pathMapping of the package name (import '@myorg/foo') or the relative paths naturally resolving to source locations.

If you instead open a subdirectory in the editor, then yeah you can do a build first to populate the output tree, and afterwards the language service can resolve imports into that tree. I think pretty much every build system does a bad job of supporting this case where relative imports are to a location in the repository but not open in the editor?