Community
Participate
Working Groups
Consider the following snippet: <html> <script type="application/javascript" src="foo.js"></script> </html When we create the compilation unit from that script block we should also be collecting the dependency foo.js
Added the update to the compilationUnit to check for found dependencies and the API to request them
My exact case is that I have "index.html" as the entry point for the client side JavaScript and app.js for the server. These are the two "main" programs where execution starts. Things not reachable from either, won't be called. ... not sure if this helps at all in the thinking ...
(In reply to Steve Northover from comment #2) > My exact case is that I have "index.html" as the entry point for the client > side JavaScript and app.js for the server. These are the two "main" > programs where execution starts. Things not reachable from either, won't be > called. > > ... not sure if this helps at all in the thinking ... Yes, this is pretty much what I was thinking - from index.html, we would collect all the *.js files referenced as dependencies and have them be reachable from the HTML context
As per our discussion, I wouldn't mind indicating somewhere what "main" is for my web application. For Node apps, that information is available in various files whose name escapes me at this point.
As soon as there is something I can try, can you let me know?
I have code that collects the imported scripts. Though I imagine there is a better way, I use scriptResolver and fileClient to get the script contents to pass into Tern. I can load the files in Tern via addFile or the files[] in the request (and I checked that Tern can find the files and walk them). Yet it never returns the declaration for any of the variables or functions the script adds to the global scope. I can't figure out why Tern can't find the matching type when it is in another file. Maybe on Monday Mike can debug through Tern with me.
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=a1b9d6af8db88c4d7f8127b280a285e0771c2967 I added and updated tests and have pushed the code to collect the script dependencies.
I'm wondering what is supposed to be working and what is not. I am comparing minesweeper-objects on beta3 and qa and the warnings are quite different (neither seem to be working well).
Here are the major issues: 1) Getting the file contents with correct parents into Tern We could accomplish this by creating a Tern plug-in that reads HTML files and parses out the script blocks, setting up any dependencies the same way the Require plug-in does. Alternatively we can do what I'm currently doing which is finding the script blocks client side and using the file client to load the script contents. Related issues: a) If you call addFile() with a parent and the file is already known to Tern without a parent, the new parent relationship is ignored. b) If we only pass the name of the file to Tern, it will use the file client to get the contents, but that will return the entire html file, not just script blocks. 2) Script file contents and HTML script block contents are in different scopes Tern does not treat the contents of the script file as coming from the same scope as script blocks in the html. This is a blocking issue. One potential solution was to look at the 'maybeProps' list, but there is no type associated with maybeProps. Perhaps we can merge all the script contents into a single file for Tern. 3) We don't support tooling on onclick and other event attributes. A common way to call scripts from html is using onclick attributes on elements. We don't parse out these calls when creating the compilationunit, so you can't get contentassist/opendecl/hover to work there. Creating a regex to parse out the attributes will be very hard to do accurately (not to mention performance). Maybe we can do something in an HTML Tern plug-in, like Angelo does in the Browser-Extension plug-in.
(In reply to Curtis Windatt from comment #9) > 2) Script file contents and HTML script block contents are in different > scopes > ... Perhaps we can merge all the script > contents into a single file for Tern. Hacked a proof of concept for this and it is working, at least for variable declarations. I was surprised to see no noticeable delay caused by finding and loading the file contents. However, it does not play well at all with the caching of the CU and the subsequent AST.
> However, it does not play well at all with the caching of the CU and the subsequent AST What fails? It is important that we support the "plain html" case and we may be able to do this with some restrictions (ie. inline code doesn't work but JS files work).
(In reply to Steve Northover from comment #11) > > However, it does not play well at all with the caching of the CU and the subsequent AST > > What fails? It is important that we support the "plain html" case and we > may be able to do this with some restrictions (ie. inline code doesn't work > but JS files work). Inline code is already working. It is only imported scripts. Comment #10 describes my experiment of inlining the imported scripts. In that case the major failure is that the cuProvider, astManager and Tern all have caches of the file contents. To inline the imported scripts I have to update the contents of all these caches at a time where I can resolve deferred to collect file contents. The next step is do a deep dive into Tern inferencer to figure out why the separate files are in separate scopes. If that is a bug in Tern, we can try to get it fixed in Tern. If it is expected behaviour in Tern, maybe we can pinpoint it and work around it for this case. Understanding the Tern inferencer is a steep learning curve.
In particular, something like this in an HTML file: <script src="javascript/counter.js"></script> <script src="javascript/board.js"></script> <script src="javascript/main.js"></script> Why would the files already be seen by Tern?
(In reply to Steve Northover from comment #13) > In particular, something like this in an HTML file: > > <script src="javascript/counter.js"></script> > <script src="javascript/board.js"></script> > <script src="javascript/main.js"></script> > > Why would the files already be seen by Tern? In my example I'm inlining the contents of counter.js into index.html when open declaration is called. I have different contents in index.html than what is saved in the various caches (when eslint validation was run, etc.).
(In reply to Steve Northover from comment #13) > In particular, something like this in an HTML file: > > <script src="javascript/counter.js"></script> > <script src="javascript/board.js"></script> > <script src="javascript/main.js"></script> > > Why would the files already be seen by Tern? When you invoke any of the commands in your HTML, those files are resolved and fed to Tern (building them in automatically as the dependency graph). The problem Curtis is referring to - about scopes - is that depending on how any of those scripts actually exports stuff the inferred results differ. 1. main.js defines a function declaration main. function main() {} main is leaked into the global scope (not explicitly set), so Tern treats it as a 'maybe this is wanted' and seems to be adding it to a sub-scope (not the official global scope) 2. main.js changed to assignment expression this.main = function() {} main is explicitly set in the global scope, and is inferred as such, and is easily found / used by open decl, etc. So there are a few things I can do here (once the html dep code is in git), I can force Tern to always add all unknowns to the global scope (could cause false positives in requests), or make sure to properly expose the 'maybe' scope as a fully resolved / propagated type scope rather than just the 'maybeProps' mention there is now. Curtis, can you open a new bug for the scope problem once you put some code in master that I can test with?
So I was able to track down the cause of the scoping problem. The Tern node plug-in was changing the scope the types were added to (I didn't realize that the 'exports' scope was actually a Node plug-in thing). Disabling the node plug-in and everything works great. I also have a workaround/fix for Tern not allowing me to reparent a known file. Meanwhile Mike created a Tern plug-in that does the same operations inside the Tern worker and it appears to be mostly working. We will work on it tomorrow some more to see what is working and what isn't. We plan to release the code to master, possibly with the plug-in disabled depending on how our testing goes.
(In reply to Curtis Windatt from comment #16) > Meanwhile Mike created a Tern plug-in that does the same operations inside > the Tern worker and it appears to be mostly working. We will work on it > tomorrow some more to see what is working and what isn't. We plan to > release the code to master, possibly with the plug-in disabled depending on > how our testing goes. I pushed the plugin to master. It allows Tern to directly work on an HTML file. I think the fix for bug 473964 will fix the nodejs plugin scoping issues, as it will add support to 'know' if the plugin should even be used in a given context. The git link: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=e8d5ee745bad5a419e20dba2dfeaddc0c632e11d
Pushed in support for all of the commands to directly pas the HTML to Tern: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=feea42ebec37bc63cecad36f297caadcb954aca4
This is working great! My current list of issues: 1) When adding a file the Tern does not add the parent to any known files. This doesn't seem to cause any problems opening declaration in the added files so this may not be a bug at all. Considering filing an issue against Tern to investigate further. 2) Test failures due to missing exports and module assist proposals I think that the new behaviour is more correct and better for the user, so I have fixed the tests: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=ff37afe6548ecaa9d34ce5666959fc0dbe95c532 3) Find script blocks doesn't match the spec Bug 475962 4) Types in the top level scope are available everywhere Bug 475964 This causes 6 test failures 5) Can't use tooling on onclick and other function attributes Bug 475965 We can follow up on these issues in their respective bugs. Reassigning to Mike as the HTML plug-in portion a more difficult piece than the dependency collection. Closing as FIXED.
Can you tell me what is supposed to be working? For example, in the minesweeper-object project, I try to navigate from main.js to counter.js using setValue() and it fails. Should it work? The code in minesweeper-objects is some of the simplest possible OO JavaScript around. I can open a bug report.
(In reply to Steve Northover from comment #20) > Can you tell me what is supposed to be working? For example, in the > minesweeper-object project, I try to navigate from main.js to counter.js > using setValue() and it fails. Should it work? The code in > minesweeper-objects is some of the simplest possible OO JavaScript around. > > I can open a bug report. That should be working as all of the minesweeper* stuff is dumped into the global scope. Please open a bug. The HTML -> JS case is working 100%: i.e. navigate / use assist / etc while working in a script block.
Right but being in one JS file and navigating to another should work. Anyhow, I will enter the bug.
I am a lying sack of ... Must be that I was not running the latest build. It's working like a charm!
I said I would change the assignee but never actually applied the change... (In reply to Steve Northover from comment #23) > I am a lying sack of ... > > Must be that I was not running the latest build. It's working like a charm! The behaviour currently depends on what files are in the Tern context. Everything that Tern sees in the global scope is getting added to assist proposals for all files. So if you edit all the script/html files you will get proposals for all of their types. If you have only visited the one script file, there is no way for Tern to know that some other script file contributes something to the global scope that we care about. We need to limit the proposals to just the file and its dependents (Bug 4759654). Once that is fixed, then your case (script to unrelated script) won't work at all. I opened Bug 476062 to discuss how to tell Tern a set of scripts are related.
Ok, this is pretty bad in the sense that you think something is working and it is, then it isn't etc. Will go over to the other bug.
