ModuleImport

Brian Di Palma offler at gmail.com
Sun Jun 29 14:14:35 PDT 2014


> Static checking will be limited anyway. If you want to go this way you shoud use typescript.

If you don't want static checking you should stick with ES3. Fixed that for you.

Yes big projects are possible with JS, I work on them everyday. It
would be nice if the language made them easier, that's what we are
talking about.
Big projects are possible with C, why bother with any other language?
With sufficient rigor Assembly will do the trick. Just have good code
reviews and test.

> ability to dynamically import modules in addition to static imports. IMO this should be packaged as an async API

I think this is already possible using the loader.

> hooks for transpilers. This should also be an API

Ditto.

> Usually, I obtain the same benefit running the tests (and more, test that were the product of TDD workflow)

I can forsee many people writing tests where they configure the module
loader to load mocks instead of true dependencies.
This could result in tests passing while there is a breakage in the application.

If the language can make some of these problems go away then we are better off.
It's just like tests, code review and linting, it's another type of
verification.

> I think that a possible compromise that can still make the ES6 module system more compatible with both AMD and CommonJS modules

The ES6 module system is compatible with CommonJS and AMD, I'm happily
mixing the two together with libraries like SystemJS

https://github.com/systemjs/systemjs/

For example

https://github.com/briandipalma/flux-es6/blob/master/src/Store.js

The Emitr class here is imported from a CommonJS module

> It is important to focus the design on loader issues and keep things orthogonal.

The Loader is quite solid and well designed, I've not heard any major
issues with it. What does it have to do with this discussion?

> import {foo} from './foo';
> var foo = require('./foo.js').foo;

I though those two statements weren't comparable?
The import statement can only be present at the module top level while
the require can be written in any code block.
That leaves it open to the random number require issues which makes
static checking impossible.
As you pointed out it's not a language standard so I'd imagine that's
another reason why tooling is so weak.

> Rather than point towards type-checking, I think we should focus on the actual checks offered by the module design.
> It seems that these would come with a small cost quite unlike type-checking.

Unless I'm misunderstanding Kevin I think we've both talking about
exactly that. I guess people saw "static" and automatically added
"type".
Just static checking of import and export bindings. A much smaller
scope feature then static type checking.

This discussion has veered off track, it's about a new ModuleImport
form, which grew into questioning if default imports/exports was the
real problem.
I'd be interested in knowing if it's possible that instead of changing
the ModuleImport form the default import/export idea could be
postponed instead.

It could be added in later if there really was need for it.
As far as I can tell libraries like SystemJS can smooth over issues
caused by importing from legacy module systems like CommonJS and AMD.
Leaving default imports/exports an odd third way to import that was
added based on some notion of backward compatability that wasn't
needed.


More information about the es-discuss mailing list