Design Meeting Notes, 9/21/2022

[DanielRosenwasser]

Specifying Compiler Options Under --build

#25613

• Can't really provide compiler options when building using project references with the --build mode flag.
• On the module transforms branch, we have emitDeclarationsOnly because we're using a bundler to handle JS emit - and that saves us a bunch of time.
  • But we'd like to be able to test that the compiler can still emit itself. So we'd like a target that does the same thing as our existing projects, but with emitDeclarationsOnly set to false.
• Want to build a project with all dependencies with the same updated options.

  • What about a single project with a different option?

  • Not supported here - but in theory we could do something to toggle individual project level options and not have them apply to dependencies. e.g.

    tsc --build ... --singleProjectOptions --emitDeclarationsOnly false

• Currently, all options on the command line don't change the number of outputs. Now have to do more book-keeping on this.
  • Currently, even if the project thinks it's up to date, we need to check if the command line options "match".
  • Could say any compiler-level command-line flags would be like running with --force.
  • If you build with skipLibCheck and specify it on the command line, but if the last project had errors, we wouldn't know to re-check (?)
  • composite already has affectsMultiProjectBuildInfo(?), could serialize the options and save them into a .tsbuildinfo.
• Without .tsbuildinfo, there's no way to really support this.
• Could easily make --emitDeclarationOnly, --declaration, --noEmit, --sourceMap, --declarationMap, and similar flags work here.
  • But doesn't leave you in a good state from subsequent builds. (?)
  • Doesn't seem to be the case.
• Possible that our up-to-date checker doesn't check map file emit.
• Investigate which flags.

Using dprint for Formatting

• A formatter would cut down on a bunch of our lint rules.
• Everyone uses Prettier but checker.ts is massive.
• dprint is fast enough to format the entire codebase, and enough that we don't feel format-on-save on checker.ts
• Formatting needs to be done before
• Why can't we use our own formatter?
  • Our formatter is conventional, but not prescriptive - we don't have strong enforcement on precisely how code should look.
  • If you add multiple newlines, we're not going to toss them out.
• Rust and Go ship prescriptive formatters - we ship a "non-intrusive" formatter in our LS, but it's configurable, and could be made more configurable. Maybe we should be using that.
  • Also, our own formatter is just not going to be competitive with dprint.
• checker.ts is not the only big file - so what are we saying here? We should be dog-fooding what we're shipping or possibly shipping a 3rd party formatter.
• Feels bad to not use our own tools
• We're going to need a basic formatter regardless, and it will continue shipping with the LS.
• But investing in it is tough. Older codebase, not easy to follow.
• Really 2 discussions
  • Should we use a different formatter on our own codebase?
  • What is the future of our formatter?
• Our core value prop is not the formatter - we have a decent non-intrusive formatter, but we shouldn't focus on a prescriptive formatter.
• Hey, didn't we have a similar conversation about Prettier a few years ago?
  • Yes. But dprint is fast!
• Should look at the non-prescriptive PR and see what we don't like and see if we can contribute to dprint - but also, get over some formatting nits in some cases.

[Jack-Works]

or try rome! https://rome.tools/#getting-started

[jakebailey]

I considered Rome, but it, like prettier, is intentionally opinionated and makes style decisions that don't match the repo, without any knobs for customization.

I personally have no strong style preference and wouldn't mind, but that's not everyone's opinion, and dprint can be configured to give us formatting rules that match our existing style.