Angel Java Lopez
ajlopez2000 at gmail.com
Sat Jun 28 15:51:28 PDT 2014
Maybe, I cannot see all the landscape, but a minor comment, in my "limited"
## Early Errors and Warnings ##
Usually, I obtain the same benefit running the tests (and more, test that
were the product of TDD workflow). In this way, I'm sure not only of no
removal of something I needed, but also the underlying behavior of imported
modules are still the same. Relaying on static imports only warns me about
the presence or not of some functions, but the app could be broken
Angel "Java" Lopez
On Sat, Jun 28, 2014 at 7:42 PM, Bruno Jouhier <bjouhier at gmail.com> wrote:
> Static checking will be limited anyway. If you want to go this way you
> shoud use typescript.
> Big projects are perfectly manageable with CommonJS from my experience
> with a 20+ team. The trick is to enforce code reviews and unit tests.
> CommonJS falls a bit short on the import side because static analysis of
> require calls is brittle. A special language syntax would enable a robust
> static analysis of dependencies.
> But the export side of CommonJS is basically ok. JS APIs are dynamic and
> there is little value in introducing a shallow and leaky static API
> verification at the module interface.
> Two things should not be overlooked in the design:
> * ability to dynamically import modules in addition to static imports. IMO
> this should be packaged as an async API
> * hooks for transpilers. This should also be an API
> Le 28 juin 2014 à 14:51, Kevin Smith <zenparsing at gmail.com> a écrit :
>>> Static checking of imports and exports has well-known advantages and
>>> would help the long-term viability of the language.
>> Enumerating these specific advantages would inform this discussion.
>> These advantages are not well-known. Many developers have experienced the
>> disadvantages of complex systems of rules and thus favor simple solutions
>> over ones with theoretical advantages. Explaining the benefits concretely
>> would help them balance the well-known costs.
> know what anything is until you actually run the program. Statically
> verifiable exports gives us the ability to inspect and analyze code without
> having to run it. There are two big benefits that this affords us:
> ## Early Errors and Warnings ##
> Let's say that you want to deprecate and remove an exported member from a
> module within a large JS code base. With static imports, the system will
> generate an error at compile time if something on the other side of that
> codebase is importing it.
> For exported function declarations that use default parameters to indicate
> optional parameters, we can generate build-time warnings when such an
> function is imported and called with too few arguments.
> For exported classes, we have even more static information at our hands.
> Without having to run the program, we know the number of arguments for the
> constructor and we know the list of methods for class instances. We can
> generate warnings when we see an instance using a misspelled method name,
> for instance.
> ## Computer Aided Coding ##
> The information used above to generate lint-like warnings can also be used
> to give the developer in-editor feedback. Reliable code-completion for
> imported function and class declarations becomes possible. Again, for
> exported classes we can also do code completion for instance methods.
> These advantages may not seem like a big deal now, but imagine writing JS
> in a large team five years from now. Do you want the power of static
> analysis at your team's fingertips, or do you want to be stuck with
> "anything goes so anything can break" CommonJS modules?
> Does that do it?
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss