Language services require at least one open file

[lorenzodallavecchia]

The language services provided by tsserver require at least one file to be open among the ones belonging to the scope of a tsconfig.json. A file is open if an open was sent, but no corresponding close command). With the current typescript.java architecture, this means that a TypeScript Editor must be open.

If a tsconfig.json has no file open, no language support will be available for it. This notably includes compileOnSaveAffectedFileList, but also simpler commands like projectInfo do not work.

In addition to missed compilation, this can cause all sorts of problems in Eclipse: for example when refreshing external changes, doing a Find-Replace, moving/renaming files or checking out from Git.

Steps to reproduce

In a project with compile on save enabled:

1. close all files,
2. modify a .ts file out of Eclipse,
3. refresh the file in Eclipse,

The file itself is not recompiled.

[angelozerr]

@lorenzodallavecchia I have done a fix. Please tell me it works.

[angelozerr]

@lorenzodallavecchia can I close this issue?

[lorenzodallavecchia]

Sorry for the delay @angelozerr.

I had put this bug in standby because I wanted to investigate the use of openExternalProject (as suggested on the TypeScript issues tracker). If it works, it would provide an even better solution, with support for multiple tsconfig and no need to close and reopen the language server each time.

However, since I'm very busy right now, I'll leave out the openExternalProject investigation for now.

I teted your fix and it works perfectly for the use case described here. The issue can be closed.

[lorenzodallavecchia]

I'm positing an update here, since this is still open. I did some investigation (outside of Eclipse) about using openExternalProject. The first results are promising: it keeps the client "live" and ready for compilation requests, even when all files are closed. I'm currently trying a quick implementation inside typescript.java. If it works, I'll send a PR.

[angelozerr]

Very cool news @lorenzodallavecchia! Just for your information, it's planed to create a release this month. So perhaps we could integrate your PR if you think it will work. Thanks for your help!

[probert94]

@angelozerr Should we reopen this Issue, as the PR has been reverted?

[angelozerr]

Yes you are right, but I would liek to do that after 1.2.0 release.

[jcompagner]

how is this case going? Can i test or code/look at something?

Because this is really the most annoying thing the current version (1.3) of the plugin has

Because updates through git or any other change to the file and suddenly we are out of sync, that could cause in our eclipse some weird behavior, that we think we are working on the latest files but the js files are still something old.

Currently it seems to really still be depending on a file being open in the editor.

Also when no files are open and a change happens and then i open a ts file (the one that was changed) it is still not compiled, i really have to touch it again.

[lorenzodallavecchia]

Hi @jcompagner, sorry for the delay.

The problem with recompilation is two-fold: recompiling files changed outside of the editor and cascading recompilation across different TypeScript projects (i.e. tsconfig.json files).

Recompiling when something changes, as is the case of Git checkouts, should work most of the times. If you have found specific cases that do not recompile the changed file at all, they are probably bugs that we could fix.

The issue of cascading effects between projects is the main one that I was trying to address with this PR. Unfortunately, it cannot be done in a performant way until Microsoft implements project references Microsoft/TypeScript#3469 (they have that in roadmap). For more information on this issue, see my comments on #160.

[jcompagner]

but even simple stuff really doesn't work for me

what i do, close all editors, open the js file (that is besides the ts file)

Then outside of eclipse, open the ts file in an editor and change it.

The js file is not changed by a recompile of the ts file. I have native polling on (preferences->general->workspace) or when i do refresh (Eclipse git sees the file as an outging change suddenly so eclipse does pick up the change)

even if i then open the ts file nothing happens, i really need to change the ts file in eclipse then it works

If i leave the ts file open and i change it outside of eclipse then it works

(i need to have compile on save option checked in the tsconfig file, build on save doesn't seem to do much)

So i am already happy if really always the js file is generated from any change how ever that happens on a ts file. I am fine with that other files are not directly compiled (so if they are not touched then it could be that they now have compile errors that i am missing but for now that is fine)

[angelozerr]

Then outside of eclipse, open the ts file in an editor and change it. The js file is not changed by a recompile of the ts file.

Yes it's normal, typescript.java uses standard Project Builder (like Java JDT) and it works only with IFile (file coming from the workspace) and not the file system.

There is the same problem with Java, if you change your Java class file outside the eclipse, you compiled .class file is not updated.

Why do you want to do that?

[jcompagner]

Thats not true, if i change a java file outside of eclipse in an editor And eclipse refreshes that file through native polling or by me doing a refresh on the project/file (no editor open nothing) then the builder will pick it up and compile the class...

Else this would go wrong for example with the subclipse/svn plugin, because that is implemented on windows by a native dll (the real svn client) and that alters all the files directly on disk if you do a update/checkout The plugin then says to eclipse workspace/project.refreshLocal()

So that eclipse picks it up and all the builders are starting up to see the changed files, no IFiles are used here. only refresh.

The eclipse workspace resource listeners will get the events, those listeners can be called by directly in eclipes (IFile.setContents and so on) or by Workspace.refresh() calls.

The problem somehow is that the typescript builder is working on content changes through the editor instead of really listen to Workspace resource changes.

for example code that we have: postChangeListener = new IResourceChangeListener() { public void resourceChanged(final IResourceChangeEvent event) { getResourceChangesHandlerCounter().increment(); try { resourcesPostChanged(event); } finally { getResourceChangesHandlerCounter().decrement(); } } }; getWorkspace().addResourceChangeListener(postChangeListener, IResourceChangeEvent.POST_CHANGE);

[angelozerr]

@jcompagner thanks for your feedback! I will try with JDT and see how it works.

I have supported the case when none files are opened and compilation must be done like this scenario:

• Update your ts file => js is compiled.
• Close your ts editor
• Pull your ts file from Git repository => js should be recompiled.

See my code at https://github.com/angelozerr/typescript.java/blob/566e841491fcfdd5b38170f316b1daeae2b252d4/eclipse/ts.eclipse.ide.core/src/ts/eclipse/ide/internal/core/resources/IDETypeScriptProject.java#L464

@lorenzodallavecchia what do you think about that?

[p-bakker]

@angelozerr a bit unclear on the status of what @jcompagner said about how the builder should be kicked off when files get altered outside of an editor and of which you said you'd look into it

Any chance to get a status update?

Need to make a decision about rolling out TypeScript to a group of Developers and if they need to remember to manually compile .ts resources on every pull, it's a recipe for trouble... :-)

[angelozerr]

It's in my scope, but just find time to to that. Sorry I cannot give you more info.