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 Bruno > Le 28 juin 2014 à 14:51, Kevin Smith <zenpars...@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. > > So pretty much everything in Javascript is dynamic, which is one reason why > IDE support for Javascript has always lagged behind. You simply can't 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
