bjouhier at gmail.com
Sat Jun 28 15:42:20 PDT 2014
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.
> ## 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss