Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 486300

Summary: [tern] Tern project file should give errors for bad paths
Product: [ECD] Orion Reporter: Steve Northover <steve_northover>
Component: JS ToolsAssignee: Curtis Windatt <curtis.windatt.public>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P2 CC: Carolyn_MacLeod, curtis.windatt.public, Silenio_Quarti
Version: unspecified   
Target Milestone: 11.0   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Steve Northover CLA 2016-01-21 14:12:34 EST
When I provide a path that doesn't exist in a tern project file, I get no notification that I have make an error.  For example:

{
"loadEagerly": [
	"utter/crap/public/index.html"
]
}

I conclude that the JS tooling is not working.
Comment 1 Steve Northover CLA 2016-01-21 14:13:52 EST
I realize that this is likely a Curtis sort of bug but I am continually left wondering if the tooling is working or no for the plain HTML case.
Comment 2 Michael Rennie CLA 2016-01-21 14:31:34 EST
(In reply to Steve Northover from comment #0)
> When I provide a path that doesn't exist in a tern project file, I get no
> notification that I have make an error.  For example:
> 
> {
> "loadEagerly": [
> 	"utter/crap/public/index.html"
> ]
> }
> 

We could validate paths, but we don't for the simple reason that we would end up slamming the fileClient (which already is not good performance-wise) for every entry in loadEagerly - which has no size restrictions and could contain a lot of entries.

I can definitely add in calls to check the existence / validity of paths, although that would delay the other validation while we wait for the fileClient to respond.

> I conclude that the JS tooling is not working.

That is an extreme and wrong conclusion to make for something like this.
Comment 3 Steve Northover CLA 2016-01-21 14:38:38 EST
Didn't mean to cause offense.  What I mean is that as a user, I see some errors in my code, I hear about this .tern-project file thing, I add one and edit, keep saving and making changes, get no feedback about what works and what doesn't work and then give up.

That still sounds offensive but is not meant to be.
Comment 4 Steve Northover CLA 2016-01-21 14:42:04 EST
Back to the problem.  Could you validate all of them at the same time or validate them on the server?  There is also a bug around somewhere that says we need to handle wildcards so perhaps it could be solved at the same time.

I wonder how many paths are typically in a .tern-project file?
Comment 5 Michael Rennie CLA 2016-01-21 14:53:35 EST
(In reply to Steve Northover from comment #4)
> Back to the problem.  Could you validate all of them at the same time or
> validate them on the server?  There is also a bug around somewhere that says
> we need to handle wildcards so perhaps it could be solved at the same time.
> 

Thats what I was going to try. If we can ask for all of them in one call, that would be ideal.

Are you thinking of bug 481056?

> I wonder how many paths are typically in a .tern-project file?

On average they seem to be 1-10 paths (point loadEagerly at the 'main' and have the rest be loaded by node / require plugins). But I have seen a giant one with over 30 paths.
Comment 6 Curtis Windatt CLA 2016-02-01 11:29:54 EST
When I first added the support I was putting warnings into the console when we loading the loadEagerly entries into Tern and there was a problem in the paths.  This included both finding no files at that location or finding multiple potential matches.

The timing doesn't work well to inform the user though.  The .tern-project file has already been parsed/validated and the Tern server started with the new options.  The loadEagerly happens after this and each call to the file client takes an unknown amount of time.  We would have to collect all the warnings/errors and then display them in the error status at some future time.

As Mike already stated validating the paths while you are editing the file could hammer on the file client causing problems.
Comment 7 Steve Northover CLA 2016-02-01 13:18:43 EST
I'm sorry to keep hammering on this but I would like people to make use of this feature and demo it to people.  Editing a file and having errors or nothing visible happen isn't good.

Can we verify the paths on the client (risk the slowness, tell the user what we are doing)?
Can we update the status line when we save (maybe instead of the drop down status thing)?

Thoughts?  I realize I have mixed up the "verify the path" versus "tell the guy that the tern file is being used" issue in this discussion.
Comment 8 Michael Rennie CLA 2016-02-01 13:49:34 EST
(In reply to Steve Northover from comment #7)
> I'm sorry to keep hammering on this but I would like people to make use of
> this feature and demo it to people.  Editing a file and having errors or
> nothing visible happen isn't good.
> 
> Can we verify the paths on the client (risk the slowness, tell the user what
> we are doing)?
> Can we update the status line when we save (maybe instead of the drop down
> status thing)?
> 
> Thoughts?  I realize I have mixed up the "verify the path" versus "tell the
> guy that the tern file is being used" issue in this discussion.

I'll come up with an experiment to make this work. 

Best case, I can show something in the editor per-save (or something) and take a bit of a performance hit. Worst case, I pop up our current reporter and say we tried to load the file but it does not exist (but that Tern still started just fine, as it tolerates bad / non-existant paths)
Comment 9 Curtis Windatt CLA 2016-02-09 14:55:46 EST
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=522dc2afc89c6cef263159de5a751d753645afdc
Fixed in master with a new test suite