jj101k/eximport

eximport's Issues

You should be able to do `require("foo").Foo` not `require("foo").ns.Foo`

The current eximport export datum is an object which has ns as a member containing all the namespace definitions. That works fine, but code like this:

require("foo").ns.Foo

export const Foo = "bar"

...looks bad to some systems which support both require() and import because, somewhat sensibly, they expect exports to be at the top level of the returned object.

TL;DR: require("foo").ns.Foo produces red wigglies in VS code, don't want that

Recursive mutual import can produce invalid state

TypeError: Class extends value undefined is not a constructor or null

(Edited to correct bad report)

a.js:

import { B } from "./b"
export class A {}

b.js:

import { C } from "./c"
export class B {}

c.js:

import { A } from "./a"
export class C extends A {}

The class extension fails on C

Test: Does `require()` on mutual import defer past the current execution context?

Where require() can return immediately, it should. However, currently if there's a need to defer, promises are used which most likely means it's never immediate. If it can be avoided, it should be.

`export class Foo extends Bar` is not usable in same file

The specific use-case is broadly:

export class Foo extends Error {}
class Baz {
    boz() {
        throw new Foo("foo")
    }
}

Producing "ReferenceError: Foo is not defined"

The following pattern works fine:

class Foo extends Error {}
class Baz {
    boz() {
        throw new Foo("foo")
    }
}
export {Foo}

This should return an explicit bridge object rather than an anonymous object

Returning something more nuanced than {ns: {}, importer(f)} will make it clearer when this has unexpectedly been used, as well as answering questions about how to use it.

Loading eximport breaks explicit `module.exports`

If you load a module which has an explicit module.exports =, this presumes that an export is in effect and returns a bridge, which breaks the original export.

Publish this

Seriously I keep using it so why not publish it

Test: Does explicit export of an import-derived symbol work in mutual dependency?

bar.js:

import {foo} from "./foo"
export var bar = foo + 1

foo.js:

import "./bar" // for whatever reason
export var foo = 41

My suspicion is that this does not work at all. In most patterns this isn't a large problem because evaluation of deferred import is at runtime not load time.

Add tests for deferred behaviour

These are currently untested but MAY be used by callers