Copy default compiler options for inferred projects from VS Code client #887
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR aligns inferred project compiler options with VS Code client defaults, replacing allowSyntheticDefaultImports with esModuleInterop and adding commonly used flags.
- Added comprehensive default compiler options (module, resolution, target, JSX, source maps, etc.)
- Replaced
allowSyntheticDefaultImportswithesModuleInterop - Ensured inferred projects mirror editor behavior
Comments suppressed due to low confidence (3)
internal/project/service.go:719
- [nitpick] Consider adding a comment explaining the origin of these defaults (e.g., VS Code client settings) and noting why each option is included.
compilerOptions := core.CompilerOptions{
internal/project/service.go:719
- [nitpick] This large inline initialization could be extracted into a named constant or helper function to reduce duplication and improve readability.
compilerOptions := core.CompilerOptions{
internal/project/service.go:719
- Add a unit test to verify that inferred projects are created with these default compiler options, ensuring future changes don't regress this behavior.
compilerOptions := core.CompilerOptions{
| @@ -716,9 +716,19 @@ func (s *Service) getDefaultProjectForScript(scriptInfo *ScriptInfo) *Project { | |||
| } | |||
|
|
|||
| func (s *Service) createInferredProject(currentDirectory string, projectRootPath tspath.Path) *Project { | |||
| // !!! | |||
| compilerOptions := core.CompilerOptions{ | |||
There was a problem hiding this comment.
is it possible for the extension to kind of use "SetCompilerOptionsForProjectRoot" - think tsserver uses that and there was some need of this in past though i am not aware of what as i wasnt around the time this was designed.
There was a problem hiding this comment.
Personally I think we should try and avoid doing that for as long as possible; we're owning the LS now, so I think it makes sense for us to try and set this to what we think is a good idea. I think we'll need an extension point for sure, but I don't think it's needed until maybe VS or some other editor.
There was a problem hiding this comment.
We will eventually need the ability for the client to set certain options (e.g. strictNullChecks is exposed as a VS Code option), but we should also encode good defaults ourself. Empty options are really bad, and I’m guessing there are existing third party TS Server clients that don’t use setCompilerOptionsForInferredProjects and have really bad default behavior.
|
Hm, tests do not like this 😄 |
Taken from a TSServer config message, replacing
allowSyntheticDefaultImportswithesModuleInterop