Community
Participate
Working Groups
We are working towards supporting a browser workflow (Bug 465816) where mutliple scripts contribute to the global (browser) scope and types can be called from any script or html file. In HTML files we can add any included script files as dependencies. However if you are in one of the script files there is currently no way to indicate that another script file is related. Putting all types added to the global scope into the Tern context will result in a lot of garbage in content assist (Bug 475964). So it should be filtered to the current file and its dependencies. If Tern has seen an HTML file that includes both scripts, we could potentially walk the parents of a script to see other potential related (sibling) scripts. This does require that tern reads the HTML file, either by the user opening it in the editor or by having the user indicate the root page of their project. Another potential fix would be to create a tern project file for the project which would list out which scripts are related. http://ternjs.net/doc/manual.html#configuration
Some thoughts: Every program has a main. If we can determine the main, we can trace all it's dependencies. This will work for programs, but not for libraries where an API is provided, but no main calls it. I'd like to understand the garbage in the content assist a bit more. The "garbage" seems right ... but maybe I don't understand how bad it will be.
Is there an expression I can run or something that I can do to provide the set of files for Tern to look at manually?
(In reply to Steve Northover from comment #2) > Is there an expression I can run or something that I can do to provide the > set of files for Tern to look at manually? That would be the idea of providing a tern-project file. In it you would list the files you want Tern to always look at (or the main file js/html that links to everything). We would have to build some sort of UI workflow to create/edit it.
Can you give me an expression that I can execute that takes a list of files for Tern to load? (if this is easy)
For the browser flow, can we not simply traverse all HTML files that we see? For the Node.js flow, can we start by looking for manifest.xml? For the RequireJS flow, do we have any issues here?
(In reply to Steve Northover from comment #5) > For the browser flow, can we not simply traverse all HTML files that we see? Yes it could be done. It could potentially be a large graph, but I think the bigger issue would be the operation itself. 1) Search workspace for all HTML files, 2) Give each html file to Tern, 3) Tern looks up any imported scripts and processes those as well, 4) Repeat the entire process for each open tab. > For the Node.js flow, can we start by looking for manifest.xml? > For the RequireJS flow, do we have any issues here? We don't have the same concerns as the dependencies of your script file are specified in your script file. The HTML case is different as it is possible for 2 scripts to have no explicit dependency on each other, yet share functionality due to them both being available in a browser tab.
So for the RequireJS and Node.js cases, not navigating to a declaration is a bug (Michael had a patch that found more cases ... did that ever get released?) For the HTML case, yes the graph could be huge but we won't know until we try. Can we try? If the operation takes a long time, we can put up a dialog "Computing dependency information ..." with a cancel button. We don't need to do this for the first cut. Dark launching something that would compute the information would be good enough to see how bad it was. Would it be an operation that we would do on the server? (ie. search the project for all HTML files, compute reachable JS and CSS files, return the list etc.)
(In reply to Steve Northover from comment #7) > So for the RequireJS and Node.js cases, not navigating to a declaration is a > bug (Michael had a patch that found more cases ... did that ever get > released?) I believe you are talking about renaming things other than variables. That change has not been applied because we can't be sure that the changes are valid (also why Tern does not support rename in those cases). > For the HTML case, yes the graph could be huge but we won't know until we > try. Can we try? If the operation takes a long time, we can put up a > dialog "Computing dependency information ..." with a cancel button. We > don't need to do this for the first cut. Dark launching something that > would compute the information would be good enough to see how bad it was. > > Would it be an operation that we would do on the server? (ie. search the > project for all HTML files, compute reachable JS and CSS files, return the > list etc.) Computing the graph could be done on the server, but then all of the files would have to be loaded into Tern, requiring file operations on the client side for anything not already cached.
We need to make some progress on this. Would a list of .html files help? These would be the roots where you could find all referenced JS files. Could we start by adding this API to feed Tern and then worry about whether it will come from a configuration file at a later time?
Curtis, I thing I am safe in asserting that most web pages do not use RequireJS. This means that most people will not get the benefit of any of our advanced tooling such as 'got to declaration' or 'references and implementors'. These work flows need to be supported, even it it means providing a bogus file that indicates the various "HTML main(s)".
One comment about adding 'garbage' to the CA suggestions...there's an ongoing thread on the platform-ui-dev list that started by pointing out that the CA proposals for the JDT are too 'loose' (i.e. too many off topic suggestions) compared with IDEA. I think the takeaway is that we should really try to limit the proposals as much as possible....but it'd still be nice to be able to see what the result looks like.
(In reply to Eric Moffatt from comment #11) > One comment about adding 'garbage' to the CA suggestions...there's an > ongoing thread on the platform-ui-dev list that started by pointing out that > the CA proposals for the JDT are too 'loose' (i.e. too many off topic > suggestions) compared with IDEA. > > I think the takeaway is that we should really try to limit the proposals as > much as possible....but it'd still be nice to be able to see what the result > looks like. I thought the discussion in JDT was about quick fixes. It is something to keep in mind though. If we have a way for the user to control their context, then we likely should filter anything outside of that context that happens to be in the global scope. I think some versions of Sublime limited the content assist list to 50 or so items. In HTML there is no categories/priorities so it just shows the first entries alphabetically (which isn't helpful).
Current state of my work: I'm sticking with .tern-project files as the format, but the Tern library doesn't actually do anything with them by default. We can't simply pass in a .tern-project file during server startup. Because we have to parse them (JSON) and do all the work ourselves, we can use other formats (project.json). I created a temporary new command called Add Context. The will check your project root for a .tern-project file, read/parse it, iterate through all 'loadEagerly' entries, run scriptResolver to find those files, then add each to Tern. This works for relative paths and both JS and HTML files. It doesn't support patterns */*.js and does not have great feedback for the user because of the asynch nature of the worker and file operations. Once we are happy with the behaviour the operation will be carried out automatically when you open an editor/change projects. The other big benefit of a .tern-project file is limiting the libs and plugins Tern starts with. I have added support to ternWorkerCore to allow the server to be started up with a specific set of options. When the user changed projects to one with different plugins we would shut down the worker and start a new one with the new options.
A couple things. Is this dark launched? If you have an add Context, you will also one day need a remove? Can you post a link to what the format of the file is? I realize that this is temporary code to get us going but in the long run, if we keep the idea of a file, we'll need to watch when it is saved and recompute all the tern info. Personally, I would look to see whether RequireJS or Node modules are used and if not, assume it was HTML. I'd trace all JS files that I could get to from all HTML files. Another ideas is to have a Project Type set somewhere and act accordingly. If the project type is not set, then we would not attempt to run any tooling that we know won't work.
As the .tern-project file is JSON, we should ensure it has JSON as its content type for syntax colouring. (In reply to Steve Northover from comment #14) > Is this dark launched? Will be soon. I have conflicting changes with the ongoing references work and the worker startup changes affect the testingWorker. > If you have an add Context, you will also one day need a remove? No. The goal is to have the server reset the context when switching projects. Note that this already happens, the more files you visit the more type context gets added, but every 40 or so operations Tern is reset. > Can you post a link to what the format of the file is? The link is in comment #0 http://ternjs.net/doc/manual.html#configuration > I realize that this is temporary code to get us going but in the long run, > if we keep the idea of a file, we'll need to watch when it is saved and > recompute all the tern info. Editing a .tern-project file would have to mark it dirty so the next time you go to the JS/HTML editor the tooling would restart the server. > Personally, I would look to see whether RequireJS or Node modules are used > and if not, assume it was HTML. I'd trace all JS files that I could get to > from all HTML files. We can look at different ways of helping users create a .tern-project file or other options for adding contents to the context after. > Another ideas is to have a Project Type set somewhere and act accordingly. > If the project type is not set, then we would not attempt to run any tooling > that we know won't work.
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=0b441725a138134c1a094ebf18a63ada716179ed I pushed the command (darklaunched) to master. If you run the add context command from a js or html editor, it will look for a .tern-project file at the root of the project. Example: { "loadEagerly": [ "public/javascript/extras.js", "Minesweeper/public/index.html", ] } Couple of caveats: 1) If you have bad JSON grammar or the tern-project file can't be found nothing will happen. 2) We use the scriptResolver to find the file you are talking about (notice how in the above exmaple on entry specifies the project name Minesweeper while the other doesn't). If you put in a path that happens to match multiple files in the workspace we simply choose the first one returned.
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=c805c662701cece36324d5e8fdfb268972dcc9e0 Adds tern-project to JSON content type Cleans up addContext to improve performance Limits the script resolution to the current project
I am not convinced that having this file is a good long term strategy. Keeping it up to date will be painful and will require that we watch when every single JS or HTML file is edited
I used your example file and of course, I didn't have extras.js. I got an error message the first time, I deleted the line. Tried again, it worked, then I added the offending line and got no error message. Shall I enter a bug for this?
(In reply to Steve Northover from comment #18) > I am not convinced that having this file is a good long term strategy. > Keeping it up to date will be painful and will require that we watch when > every single JS or HTML file is edited - The other fields (plugins, libs, etc.) in the file are important too as they have the potential to significantly decrease Tern startup time and improve results. - Many existing projects will have .tern-project files already. Having their Tern settings work in Orion the same as other editors will be a string selling point. - Using this file doesn't change our existing ability to track changes. Today if you use another tab to modify a file's contents, Tern running in other tabs won't know about those changes. If you visit the modified file, Tern gets the updated contents. - There is definitely going to be a discoverability/workflow issue with this. Using a known file format doesn't make this any worse. It may be the case to support the HTML case we use the infrastructure I'm building to add content from a workspace search (*.html) and never create a .tern-project. (In reply to Steve Northover from comment #19) > I used your example file and of course, I didn't have extras.js. I got an > error message the first time, I deleted the line. Tried again, it worked, > then I added the offending line and got no error message. Shall I enter a > bug for this? I didn't want to spend too much time handling errors gracefully in the command as it will all be moved into the Tern message passing. If you want to list steps here or on a new bug I will look into though.
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=9c97a0353197892ae3353228855e47e1c7420db6 Adds support for the plugins field in .tern-project files. If you have a plugins list, the Tern server will be restarted with only the listed plug-ins installed. "plugins": { "requirejs": { "baseURL": "./", "paths": {} } }
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=a19fc8c5bad419fd94f44f82716684bacbb9b23d Support for more settings in .tern-project Watch for user editing .tern-project file Bug fixes and cleanup Next step will be a command or some other workflow to help users add files to the .tern-project file. This is close to being ready for release. Not sure what to do for error reporting (bad JSON, no file found, multiple files found). I'll file separate bugs to track the remaining (non-blocking) issues.
Another issue that should be fixed before release: - Currently we always start the Tern server at the same time as the worker with default options. If you have a .tern-project file we immediately restart the server with the new options. We should skip the first step and check for a .tern-project file when the javascriptPlugin loads. - The Tern settings page may have some odd behaviour after the above change as the list of installed plug-ins will change based on the project you are in. Perhaps we should just disable this page until we have support to install/uninstall plug-ins in Tern.
I just committed a change that un-darklaunches this feature. If you have a .tern-project file in your project, we output the parsed contents of the file to the console. We also put messages to the console on errors.
I believe we now support tern project files. Further work needs to happen to allow them to be modified or to indicate in the UI that we are using them, or tell when there is a syntax error. Right now, you can look at the console. If we are keeping with the "edit the file" approach, we'll need a status message that says we processed the file and it was good or it was bad. Where is the bug that is tracking awareness of the file in the UI?
(In reply to Steve Northover from comment #25) > Where is the bug that is tracking awareness of the file in the UI? https://bugs.eclipse.org/bugs/show_bug.cgi?id=481063 Though I will open a bug for the informing the user about problems (and success?) in loading the file.
Please do. Right now, I edit the file and have no idea whether my changes applied or worse, if I have a syntax error, I never know. We should figure this out ASAP.
(In reply to Steve Northover from comment #27) > Please do. Right now, I edit the file and have no idea whether my changes > applied or worse, if I have a syntax error, I never know. We should figure > this out ASAP. Created Bug 481533 - [tern] Inform the user to .tern-project status I'm marking this bug as FIXED. Further work should fall under one of the 6 other bugs hanging off this one.
