can not correctly generate tags against jquery
Closed this issue · 7 comments
Hi Claus,
I just tried to use estr to generate tags against jquery. but tags file generated is not correct and it can't be used with taglist/tagbar or vim tag based command.
Any idea?
Hmm, I haven't used estr
in a while, but running it over jquery-2.0.1.js seems to create a working tags
file for me.
Can you be more precise?
These days, there are better alternatives, based on type inference and heuristic plugins, eg, marijnh/tern_for_vim (there is a tag file generator based on tern, but tern supports jump to definition directly, so you shouldn't need tags anymore)
Thanks for your reply. I am trying to find a good javascript tags generator recently. but found a lots of projects (like jsdoctor etc) was not actively maintained. i found estr in github. I just use the command line tool to generate tags. (node estr.js tags jquery.js) but found the tags file generated is completely wrong. I will try other tern_for_vim later. Thanks.
Yes, I used a patched doctorjs to generate tags at first, then gave up on that and used estr instead. These days, I use tern for JS and typescript-tools for TypeScript - jump to definition without tags file generation.
You haven't explained what you mean with "wrong", and it works for me (just not as precise/useful as it could be), so I'll close this.
Hi @clausreinke , I can email u my tags generated using node estr.js tags jquery.js (2.0.3) for your reference. because i can't upload the text file or post the tag here. it's too big and exceeds max length restriction. It's obviously not correct and a lots of core functions in jQuery are not included (like addClass, each, isFunction etc). and when u jump to the function definition with ":tag function-name", you will get "tag not found: addClass".
estr only parses the file then traverses the AST while keeping track of variable scope. That is all static information only. The result is not incorrect, merely incomplete (there are missing tags, as estr doesn't understand the code).
jquery, like many JS libraries, builds its export interface dynamically (in this case, via jQuery.fn.extend
), so getting full information is only possible by running the code, which is out of scope for estr. So no need to send your tags file.
Alternatives are:
- type analysis/abstract interpretation of the code, to predict some aspects of running it
- built-in knowledge of often used library operations, especially for things similar to
jQuery.fn.extend
- user-specified information for code that is expensive to analyze (or cannot be analyzed statically)
Tools like tern or typescript's language services (among a few others) already use combinations of these techniques, so I did not want to duplicate their work by extending estr.
@clausreinke , I tried another statically analyzed tool (javascript-ctags https://github.com/andersjanmyr/javascript-ctags, which also depends on esprima) and it can generate very complete and useful tags information against jquery. all the problems mention above are gone. when i compare the two tags, they are totally different. You may give it a try.
Thanks,
-Larry
when i compare the two tags, they are totally different
There are various JS tags file generators out there, with different priorities:
- javascript-ctags is very simple: no lexical scope knowledge, no static analysis; just parsing and AST traversal
- jsctags has/had a complex static analysis phase, but no way to express knowledge about lexical scope
- estr has no real static analysis, but knows about lexical scope and can express it via scoped tags files
Modern tools like tern are not limited by tags files, know about lexcial scope and have a type analysis phase, and have plugins supporting common JS module system.
So, both of jsctags and estr have advantages over javascript-ctags, and tern has advantages over all three. I do not know a single reason to use tags files with JS anymore, when tern can do so much more.
(the reason that javascript-ctags covers addClass
is that it treats all object properties with function values as globally available; this is terribly imprecise, but often useful - I had planned to add it to estr - #1 - but switched to helping the tern plugin for Vim instead)