Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 2/25/2022 #48042

Closed
DanielRosenwasser opened this issue Feb 25, 2022 · 3 comments
Closed

Design Meeting Notes, 2/25/2022 #48042

DanielRosenwasser opened this issue Feb 25, 2022 · 3 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

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.

@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Feb 25, 2022
@DanielRosenwasser
Copy link
Member Author

CC @alexeagle

@DanielRosenwasser
Copy link
Member Author

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?

@alexeagle
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants