Community
Participate
Working Groups
Now that we have a really cool AST plugin for acorn, we should add in support to pre-resolve paths and tag the corresponding AST nodes. For example: 1. define(["path1", "path2"], function() {}); -> path1 and path2 would be resolved during the parse phase and the workspace path would be added to the literal nodes 2. require('async') -> async would be resolved and the literal tagged 3. importScripts('./foo/bar') -> ./foo/bar would be resolved and the literal tagged etc. The benefits of this have the potential to be a huge time saver, since the paths remain valid as long as the AST is valid - for example: 1. hover would no longer ever need to ping the file client 2. linting rules can ask the literal directly for infos and react accordingly - without pinging the file client 3. Tern plugins would no longer need the resolver class, and our tern integrations would require far less work, since we would not have to hook in the resolver class
We should also investigate loading types mentioned in JSDoc, and tag doc nodes with the name mapping. This would finally allow content assist, etc to work properly for doc'd types that have not been loaded into Tern (because now we could load them correctly without an explicit requirejs / node entry).
New Gerrit change created: https://git.eclipse.org/r/70791
(In reply to Eclipse Genie from comment #2) > New Gerrit change created: https://git.eclipse.org/r/70791 In this commit, I moved the file resolving from resolver.js to orionAcron.js and successfully attached the result to the AST node that can be used by both node.js and requirejs.js plugins when they are asked to calculate type information. Thus, the original resolver object in the two plugins become useless and has been removed. Besides, I also removed the fix that comes from bug 481271 (javascriptPlugin.js) since orionAcron.js has did the same thing while parsing. There are still some problems of this commit: 1. This commit cannot handle multiple-level loading. If a loaded module requires its own dependencies, the result seems to be invalid. (I think this problem exists before this commit and have pointed it out in Bug 481271 at comment 30) 2. To resolve files, orionAcron instance needs to access ternServer. In ast.js, we have that access but in astManager.js, we do not. I tried to put the server into OrionAcorn.prototype, but it failed to share between the two orionAcron instances. This is caused due to the closures created during module loading process. There is a example I wrote to show this phenomenon and I will add it as an attachment.
Created attachment 261162 [details] Failure of sharing ternServer using prototype scheme Run this code in node.js and the result will show that oa2.ternServer is undefined.
Created attachment 261163 [details] Failure of sharing ternServer using prototype scheme and One possible Solution
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04002.html
Reopening
Created attachment 267949 [details] Patch from gerrit This is the change from gerrit: https://git.eclipse.org/r/#/c/70791/
