Comments for Programming, Languages, Tools

Comment on Loading Javascript Modules by Eric Bréchemier

Eric Bréchemier — Wed, 07 Nov 2012 11:06:31 +0000

ES6 modules will be a much needed addition to the language, but after the completion of the specification, several more years will pass until browsers that do not support ES6 fall into oblivion.
In the meantime, I would like to have a simple way to declare modules to ensure that I won’t need to modify every single script to take advantage of ES6 Harmony for example.
I find that the transition from namespaced modules to AMD is too steep, with a long tunnel effect caused by the inversion of control.
I am fine with a temporary solution, local to a single project if need be. I am definitely not interested in implementing yet another loader, but I am not looking forward to rewriting a whole code base to adapt to yet another module system.
What I am looking for is something partly similar to the Loader API of ES6:
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders
but simpler to implement, and adapted to today’s module definitions.

Comment on Loading Javascript Modules by libraryinstitute

libraryinstitute — Tue, 06 Nov 2012 23:20:48 +0000

Yes, using function wrappers as parameters to a function with varying definitions to give control over the transition was a core idea in the transition I outlined in this post. But even back then, my definitions were temporary/project-local – the time for advertising “yet another module loader” is long past. AMD-based loaders were a hard enough sell, and they seem to cover the ground well (including adapters for other module systems, without another level of abstraction on top).

Over the next year, I expect the focus to shift towards ES6 modules, partly supported natively, partly transpiled into AMD or CommonJS (as in TypeScript, for instance), for not-yet-supporting engines. Time to work out the remaining issues in that spec, so that we can put the module system variations behind us.

Comment on Loading Javascript Modules by Eric Bréchemier

Eric Bréchemier — Tue, 06 Nov 2012 10:15:07 +0000

I also experienced this need for a progressive transition from modules declared synchronously in the global scope to module declared asynchronously by wrapping the declarations in a definition function.
With this in mind, I developed a library called scopeornot:
https://github.com/eric-brechemier/scopeornot
It proves a useful tool, which helped me to migrate several projects to a more modular architecture.

Comment on Introducing ESTR (ES traversals and transformations) by libraryinstitute

libraryinstitute — Tue, 30 Oct 2012 21:27:44 +0000

I haven't used doctorjs/jsctags recently, but parts of my modifications/fork were to make it work in Windows (however, I consider the original project effectively dead, so won't invest time in further fixes to my fork). estr tags . is recursively processing the directories for .js files, including code installed in ./node_modules. It is currently limited to scope-related tags (variable and function declarations, parameters; not object properties), whereas my earlier implementation also inherited some approximations for non-scope-related tags, from the original jsctags. I have filed a github issue to remind me to do something about this. Since Javascript mixes variables and properties for definitions, with no static restrictions for the latter, a proper "jump to definition" isn't as easy as in other languages, but estr should do a better job, even if only adopting approximations. If you can reproduce the issue of keybindings not finding tags that should be in scope (“Ctrl + ]” will ignore scoping when looking for tags), please open an issue for this, with instructions on how to reproduce, and I'll have a look.

Comment on Introducing ESTR (ES traversals and transformations) by mcr

mcr — Tue, 30 Oct 2012 09:47:01 +0000

Hi,
I followed your article regarding jsctags and managed to set it up on my home computer (linux), but I was having problems with installing it on my work computer (windows). Than I saw this article and tried to use estr generated tags with vim.
I’m able to make tags file with: “node c:\path_to_estr\estr.js tags .” – where dot is file containing my project .js file.
tags file looks big but doesn’t contain much useful info. There are many lines like:
…
advance ./node_modules/estr/esprima.js 1045;” f lineno:1045 scope:40:2-3550:1
binding_scope ./node_modules/estr/scope_utils.js 69;” v lineno:69 scope:57:10-162:1
…
There are only few lines which refer to my .js file, and they point to simple variable declarations like:
var Main = { };
or
var keyCode = event.keyCode;

Moreover when I use default key bindings from scoped_tags vim plugin, I’m getting for e.g.:
tag keyCode not found
but “Ctrl + ]” works and I can jump to declaration.

Jumping to declarations, finding definitions is essential for my work flow, and it’s only thing which is stopping me from using vim as my main toll for bigger javascript projects.
Please could you guide me or make a tutorial on how to get such functionality in vim?

Comment on Introducing ESTR (ES traversals and transformations) by Scoped tags support for Javascript, in Vim | Programming, Languages, Tools

Scoped tags support for Javascript, in Vim | Programming, Languages, Tools — Mon, 18 Jun 2012 14:49:07 +0000

[...] Programming, Languages, Tools Just another WordPress.com site Skip to content HomeAbout ← Loading Javascript Modules Introducing ESTR (ES traversals and transformations) → [...]

Comment on Scoped tags support for Javascript, in Vim by majutsushi

majutsushi — Tue, 24 Apr 2012 16:27:52 +0000

I know what scope is, and this is not really a Tagbar issue. Yes, your range information does refer to the lexical scope once interpreted. My point is just that calling it by the semantic name “scope” seems to imply that it’s independent of changes to the physical representation of the code in a source file. For example, if I add or delete some lines at the top of the file, the actual lexical scope of a tag (as interpreted by the language) does not change, but the information in your “scope:” field is no longer accurate and could even refer to a different class or something else (it’s of course not very likely to line up perfectly somewhere else, but it’s theoretically possible), at least until the tag file gets updated. So all I’m saying is that in my opinion a name that reflects the fact that the field contains information about the *physical representation* of the scope, and not about the semantics (like the name of the enclosing scope), would make more sense. Maybe a name like “scoperange” would be best so the meaning is completely clear.

Comment on Scoped tags support for Javascript, in Vim by libraryinstitute

libraryinstitute — Mon, 23 Apr 2012 15:59:00 +0000

Actually, neither doctorjs nor ctags use 'scope'. Ctags uses 'class' for class members, it does not support lexical scope at all. Some languages introduce class members into the scope chain (I think C++ members are directly accessible in class methods), some don't (since 'with' is deprecated, JS separates object property accessibility from variable scope). This is not a question of how the information is represented in the tags file, it is a question of whether we are talking of variables and their scope or object/class members and their accessibility - two separate concepts. The 'scope' field in my doctorjs-based tags generator describes lexical scope (the only reason for using a range-based representation is that this is something Vim can understand and handle, independent of source language). If that causes problems for tagbar users, I could add a field-renaming option, but I'd rather stick to standard terminology here.

Comment on Scoped tags support for Javascript, in Vim by majutsushi

majutsushi — Sun, 22 Apr 2012 03:46:52 +0000

It’s not really about doctorjs choices in particular, ctags does the same thing with regard to the “class:” fields etc., and I think that’s actually the right thing to do. Those fields give information that tell you something about the semantics of the tag like “this tag appears in the scope of class X”, independent of how the information is actually represented in the source files. Your “scope:” field however gives the physical range of where the tag is valid *in the source file* and only acquires its semantic meaning of “scope” if it gets interpreted correctly by Vim (or any other compatible program). Therefore I think it would make sense if the field name reflects this difference between physicality and semantics. It’s a relatively minor issue of course, but I do think it would be more consistent.

Comment on Scoped tags support for Javascript, in Vim by libraryinstitute

libraryinstitute — Sat, 21 Apr 2012 13:58:22 +0000

Thanks. Yes, the confusion is sad, but ‘scope’ is the standard CS term here, while ‘class’, ‘interface’, or ‘type’ might have been used for the ‘is this property access going to work’ use. doctorjs’s namespace inference has been broken for so long that I’ve given up hope for bringing the two together. Perhaps it is time for newer JS analysis tools to return to standard terminology? On the other hand, I understand that you need to support the choices made by tag generators, whether or not you agree with them.