Skip to content
This repository has been archived by the owner on Aug 4, 2021. It is now read-only.

Use LanguageService as solution for emit-less types and semantic diagnostics #84

Closed
wants to merge 1 commit into from

Conversation

kryops
Copy link

@kryops kryops commented Jan 23, 2017

This PR adds a useLanguageService option to the plugin. It uses the TypeScript LanguageService for compilation instead of the existing typescript.compileModule() functionality.

Pros

Cons

  • Slower compilation
  • More complex API

Unresolved issues

  • Typings in node_modules/@types aren't discovered automatically with my current LanguageService implementation. As a workaround the names of all folders in node_modules/@types are set as compilerOptions.types if none are present already.
  • I could not get the tests to run and thus didn't add any new tests. I got the following error message:
TypeError: Path must be a string. Received 6
    at assertPath (path.js:7:11)
    at Object.join (path.js:1211:7)
    at Object.<anonymous> (/home/michael/git/rollup-plugin-typescript/node_modules/buble/register.js:41:22)
    ...

Any feedback or help regarding the unresolved issues is greatly appreciated!

@tsbehlman
Copy link

This fixes #43 for me ❤️

@PaulBGD
Copy link
Collaborator

PaulBGD commented May 23, 2017

This is very cool, I'm definitely interested in integrating it into #91. Would you like to rebase the PR off the progress branch? Otherwise I can do it myself.

@kryops
Copy link
Author

kryops commented May 23, 2017

@PaulBGD I don't have that much spare time at the moment, might be able to do it on the weekend. Feel free to give it a try yourself if you can't wait 😉

As a basis for this PR I used the following documentation: https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API#incremental-build-support-using-the-language-services

@PaulBGD
Copy link
Collaborator

PaulBGD commented May 23, 2017

Thanks! I'll check it out :)

@PaulBGD
Copy link
Collaborator

PaulBGD commented May 23, 2017

So quick question, why do you only throw on fatal errors when it's the 1st run?

Also closing this since I integrated it with #91. Everything looks great.

@PaulBGD PaulBGD closed this May 23, 2017
@kryops
Copy link
Author

kryops commented May 24, 2017

I'm pretty sure that was to stop it from crashing when I'm in watch mode and introduce a TypeScript error. I want the initial build to fail when it has errors, but once the watch mode is running, I don't want to have to restart it every time I introduce an error

@PaulBGD
Copy link
Collaborator

PaulBGD commented May 24, 2017

That's actually a rollup-watch error, I'll see if I can get that fixed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants