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

For editing experience, use source instead of .d.ts files from project references #32028

Merged
merged 33 commits into from Sep 24, 2019

Conversation

@sheetalkamat
Copy link
Member

sheetalkamat commented Jun 21, 2019

Instead of using .d.ts files from project references, use their original source files to give better editing experience.
I have played with this on our own compiler sources (eg. adding methods to public api of compiler and getting it reflected in services without having to build .d.ts file and also tried sample module scenario to see same behavior.

I would like to get the feel of the experience before actually working on remaining to dos

Things yet to look into:

  • errors in the project -> Skip type checking (so error reporting) on sources of project reference redirect
  • compile on save -> do not emit files that are sources of project reference redirects,
  • compile on save -> add error if compileOnSave is enabled but referenced projects don't have compileOnSave - Created #33270
  • Fixing tests
  • Implications on memory and what can be done for exploding project size -> Add compile option to disable including sources of project reference redirect - option is disableSourceOfProjectReferenceRedirect
@sheetalkamat sheetalkamat changed the title [WIP] References prototype source file [WIP] For editing experience, use source instead of .d.ts files from project references Jun 21, 2019
src/server/project.ts Outdated Show resolved Hide resolved
@microsoft microsoft deleted a comment from typescript-bot Jun 21, 2019
@microsoft microsoft deleted a comment from typescript-bot Jun 21, 2019
@microsoft microsoft deleted a comment from typescript-bot Jun 21, 2019
@microsoft microsoft deleted a comment from typescript-bot Jun 21, 2019
@ajafff

This comment has been minimized.

Copy link
Contributor

ajafff commented Jun 23, 2019

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:

  • Does this work with different compilerOptions in the referenced project (strictNullChecks, noImplicitAny, moduleResolution, paths, ...)?
  • Will autocomplete show //@internal symbols from the referenced project because they are not yet stripped out?
  • Assignability might be different from batch compilation when types of private properties are removed.
@sheetalkamat sheetalkamat changed the base branch from master to noDtsWhenNotUsingProjectReferences Jun 27, 2019
@microsoft microsoft deleted a comment from typescript-bot Jun 27, 2019
@microsoft microsoft deleted a comment from typescript-bot Jun 27, 2019
@AnyhowStep

This comment has been minimized.

Copy link
Contributor

AnyhowStep commented Jun 27, 2019

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 .d.ts files.

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,
#29511 (comment)


If whatever I just said isn't relevant at all.. Just ignore me =x

@sheetalkamat sheetalkamat changed the base branch from noDtsWhenNotUsingProjectReferences to master Jun 27, 2019
@sheetalkamat

This comment has been minimized.

Copy link
Member Author

sheetalkamat commented Sep 19, 2019

Ping for review

Copy link
Member

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.

src/compiler/diagnosticMessages.json Outdated Show resolved Hide resolved
src/server/project.ts Show resolved Hide resolved
@sheetalkamat

This comment has been minimized.

Copy link
Member Author

sheetalkamat commented Sep 19, 2019

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 services program, the source files from compiler will skip type checking. (note that's for error reporting purposes)

@sheetalkamat sheetalkamat merged commit 992c211 into master Sep 24, 2019
5 checks passed
5 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
license/cla All CLA requirements met.
Details
node10 Build #45488 succeeded
Details
node12 Build #45486 succeeded
Details
node8 Build #45487 succeeded
Details
@sheetalkamat sheetalkamat deleted the referencesPrototypeSourceFile branch Sep 24, 2019
@Andarist

This comment has been minimized.

Copy link
Contributor

Andarist commented Oct 2, 2019

Would it be possible for the editor to actually compile .d.ts and write them to disk? Wouldn't this kinda give the best from both worlds (references with autocompletion etc and better performance)?

@sarpik

This comment has been minimized.

Copy link

sarpik commented Oct 2, 2019

Hello,
sorry for the possible newbie question, but how would I use this?

I've got a similar project set up as https://github.com/RyanCavanaugh/learn-a. Mine also uses yarn-workspaces, but the point's the same.

It currently works for me using tsc -b -w, but tsc -w does not.
What am I missing? Or am I doing this wrong and I shouldn't even have to use tsc?


PS
I'm using typescript: 3.7.0-beta @ package.json and in vscode, as explained in https://code.visualstudio.com/Docs/languages/typescript#_how-can-i-use-the-latest-typescript-beta-with-vs-code


PPS
I tried installing typescript as a dependency to the project's root using yarn add -W typescript@beta and then aliasing a tsc script to run tsc.

Running yarn tsc -b -w fails

<filename>:69:420 - error TS2307: Cannot find module '@my-project/local-package'.

(it seems like outDirs aren't created & no there's no output)

but running tsc -b -w (from my global installation of typescript@beta) succeeds.
I thought this could be related.

Edit: #33770

@vilic

This comment has been minimized.

Copy link
Contributor

vilic commented Oct 22, 2019

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 shared but now it's shared/src/library.

The shared module is a linked module which is also one of the referenced projects, it has package.json with types set to bld/library/index.d.ts and I guess that's why the auto import path worked as shared instead of shared/bld/library.

@sheetalkamat

This comment has been minimized.

Copy link
Member Author

sheetalkamat commented Oct 22, 2019

@vilic can you please share your repro code so we can investigate practical scenario and solutions based on that ...

@vilic

This comment has been minimized.

Copy link
Contributor

vilic commented Oct 23, 2019

@kenotron

This comment has been minimized.

Copy link
Member

kenotron commented Oct 23, 2019

@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):

image

For a quick way to verify this, I prepared a monorepo for you to check it out:

https://github.com/kenotron/TypeScriptMonoRepo/tree/ts3.7

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.

@jquense

This comment has been minimized.

Copy link

jquense commented Oct 30, 2019

Seeing the same behavior as @kenotron In the mono repo setups we have building is still required as far as I can tell

@sarpik

This comment has been minimized.

Copy link

sarpik commented Oct 30, 2019

@jquense #34723 and #34743. It's been fixed and you can try it as described here (or just use typescript@next). It's just not available (yet?) with typescript@beta.

@jquense

This comment has been minimized.

Copy link

jquense commented Nov 2, 2019

Thanks i'll give it a try i've been using the latest RC, so maybe it's a bit behind?

@AnyhowStep

This comment has been minimized.

Copy link
Contributor

AnyhowStep commented Nov 8, 2019

Weird. I remember there being a comment that says how to disable this. But I can't find the comment anymore.

Seeing disableSourceOfProjectReferenceRedirect to true should work

@osdiab

This comment has been minimized.

Copy link

osdiab commented Nov 13, 2019

To add some color to @kenotron 's comment, my use case in a monorepo is a shared library between a Node server and an in-browser web-app.

This common library therefore has two tsconfig.json files, 2 TypeScript projects in it - one that outputs Node-compatible commonjs modules to a commonjs/ outDir, and one that outputs tree-shakeable es6 modules to an es6 outDir. Maybe there's a better way to do this, but that's what I landed on.

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 outDir, so for my setup to work TypeScript needs to know that it should forward an import to es6/**/* or commonjs/**/* to the actual source - doesn't seem like it does that.

So I'm also disabling for now.

@sheetalkamat

This comment has been minimized.

Copy link
Member Author

sheetalkamat commented Nov 13, 2019

@osdiab can you please file a new issue with your repro steps, so we can look at it.

@osdiab

This comment has been minimized.

Copy link

osdiab commented Nov 15, 2019

Ah, I think I needed to delete the tsbuildinfo files and recompile to get it to work - seems to be working as intended now. My bad!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.