David Herman (2014-01-27T22:32:54.000Z)
On Jan 27, 2014, at 2:18 PM, Marius Gundersen <gundersen at gmail.com> wrote:

> So then there would be two versions of the same module, and a module could get access to both these modules at the same time. For example, if ModuleB, which depends on ModuleA is loaded and linked, and later ModuleA is redefined, then ModuleC could depend on both ModuleB and ModueA, and would get (indirect) access to two versions of ModuleA. Is this problem preventable?

It's important to be able to modify module registration for things like polyfilling. But that doesn't mean it's something people should do in general. Note that Jason only gave you an answer in the context of the basic module loader semantics; he didn't say what will happen in the HTML semantics. In particular, we can make it an error for there to be two definitions of the same module name in the same HTML, a la:

  <script type="module" name="jquery" src="jquery1.js"></script>
  <script type="module" name="jquery" src="jquery2.js"></script>

I'm inclined to call that an error, and require imperative modifications of existing module registrations to use imperative code.

Dave
domenic at domenicdenicola.com (2014-01-31T14:43:06.324Z)
It's important to be able to modify module registration for things like polyfilling. But that doesn't mean it's something people should do in general. Note that Jason only gave you an answer in the context of the basic module loader semantics; he didn't say what will happen in the HTML semantics. In particular, we can make it an error for there to be two definitions of the same module name in the same HTML, a la:

```html
<script type="module" name="jquery" src="jquery1.js"></script>
<script type="module" name="jquery" src="jquery2.js"></script>
```

I'm inclined to call that an error, and require imperative modifications of existing module registrations to use imperative code.