Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
For editing experience, use source instead of .d.ts files from project references #32028
Instead of using
I would like to get the feel of the experience before actually working on remaining to dos
Things yet to look into:
I'm pretty excited about this. Editing experience is the only thing stopping me from using project references.
Here are some edge cases that might need to be handled:
I have a question.
Is this a thing for composite projects?
If so, I think it's possible for your editor to say that you've reached the max instantiation depth, but when building, it'll build fine.
Especially if the editor is looking at source files and compiler is looking at
The editor would have to "go deeper" to resolve types, while the compiler would not.
It would also break my current workaround for avoiding the max instantiation depth,
If whatever I just said isn't relevant at all.. Just ignore me =x
andrewbranch left a comment
Tried this out in the TS codebase and it’s such a big experience improvement. I’m really excited for this.
Can you explain what the “skip type checking” is about? I didn’t understand how that was related.
When program includes source file (.ts) instead of redirect file (.d.ts), the errors for those source files are not to be reported from that program. They are reported from the default program for the original .ts file. Eg. in our case if we are requesting errors in
I've got a similar project set up as https://github.com/RyanCavanaugh/learn-a. Mine also uses
It currently works for me using
<filename>:69:420 - error TS2307: Cannot find module '@my-project/local-package'.
(it seems like
The auto import path seems to be affected by this change. E.g. previously I have a module of which the auto import path is
@sheetalkamat - I am trying this out and noticed that it doesn't work in the case of things that are imported from the outDir rather than the src (in the case of a monorepo):
For a quick way to verify this, I prepared a monorepo for you to check it out:
Things work okay if you do "yarn && yarn build", but if I understand this feature, it is meant to address the case where you can start editing in VS Code with Intellisense even before having to build something because we're traversing source rather than output.
This common library therefore has two
My understanding was that for this setup to work as expected (as it was before 3.7 landed), it had to import from the proper respective
So I'm also disabling for now.