Detecting a Module object

# Guy Bedford (11 years ago)

If Module objects are not classes, then what would be the recommended way to detect if a given object is a Module?

Would there be a unique toString output?

# Allen Wirfs-Brock (11 years ago)

Can't. 'toString' might be a binding exported by a module so a module object can have its own toString method (or any other non export properties).

However, I've been think that it may be reasonable for Object.prototype.toString to have special case handling of Module objects. eg:

Object.prototype.toString.call(someModule) // "[object Module]"

But, what's you use case? Other than for debugging output, when would you need to check in an arbitrary object is a Module object?

# Guy Bedford (11 years ago)

Thanks, if there is some way to detect this it may well be useful.

The use case I came across it was trying to allow ES6 modules to be transpiled into AMD for use in an ES6 loader. I'm still not sure how necessary the use case is, but it definitely would need this functionality work.

# Allen Wirfs-Brock (11 years ago)

The Es6 module loader design has specific hooks to support importing from foreign module systems. However, I'll leave it to Dave or Sam to explain how to use them...

# John Barton (11 years ago)

Guy is trying to support an important path for JS developers to get to ES6 and adopt ES module loading: allow developers to mix ES6 and AMD modules. He already supports loading AMD via ES6-loader. Now he wants to allow that AMD code to depend upon ES6 modules. This allows AMD teams to transition smoothly to ES6. He needs something like:

define(['a', 'b'], function(a, b) {
  if (!(a instanceof Module)) a = { default: a }
  if (!(b instanceof Module)) b = { default: b }
....

so his generated AMD code can accept ES6 modules.

# Guy Bedford (11 years ago)

Thanks John for explaining. As for the usefulness of this path as I say it is yet to be determined.

Specifically the ability to detect a module instance is needed to allow ES6 loaders to load AMD that was transpiled from ES6 into AMD.

It may be a little bit of an obscure use case, the exact details of the use case are described in this gist - gist.github.com/guybedford/5622c9ed5c9ad4bc0417.

The key point being raised here is that there is a scenario in which detecting a module instance is useful.

# Guy Bedford (11 years ago)

Being able to do m instanceof Module is certainly a lot nicer here though.

Just to return to the consideration of modules as classes, I still don't understand what the major issue is with having a module as a class without any prototype methods.

# Allen Wirfs-Brock (11 years ago)

it's not going to be instanceof for various technical reasons.

I suspect, we can have a isModule predicate function somewhere. Perhaps, Reflect.isModule or Reflect.Loader.isModule...

# David Herman (11 years ago)

I think it should be Module.isModule.

# Domenic Denicola (11 years ago)

Is Module a global now?

# David Herman (11 years ago)

no, it's in Reflect

# Allen Wirfs-Brock (11 years ago)

On Feb 21, 2014, at 12:08 PM, David Herman wrote:

I think it should be Module.isModule.

I don't think we actually need something named Module, but that's a separate conversation I have in the queue to have with you.

But food for thought: for module loader reflection purposes, it would be better for use a mirror-like object rather than the actual magic module objects.

# David Herman (11 years ago)

OK, we can discuss and report back. We'll definitely want to take into account Guy's use case about being able to recognize module instance objects as such.

# Guy Bedford (11 years ago)

Has there been any further discussion on this? It would be good to know the form so that ES6 modules currently being generated today will not break in real ES6 environments.