tcomb crashes when there are circular "import type" about babel-plugin-tcomb

[lwchkg]

Anyway, here are the contents of the source files:

index.js

// @flow
import {A} from "./a.js";
import {B} from "./b.js";

const a = new A(null);
const b = new B(a);

console.log("A = ", a);
console.log("B = ", b);

a.js

//@ flow
import type {B} from "./b.js";
export class A {
  b: ?B;
  constructor(b: ?B) {
    this.b = b;
  }
}

b.js

// @flow
import type {A} from "./a.js";

// The following line causes the problem. Removine the line and
// s/MaybeA/?A/ makes the file runnable.
type MaybeA = ?A;

export class B {
  a: MaybeA;
  constructor(a: MaybeA) {
    this.a = a;
  }
}

[lwchkg]

I have edited the generated b.js a bit and it seems to fix the problem:

var MaybeA = _tcomb2.default.maybe(_a.A, "MaybeA");

becomes a lazy evaluating function with closure:

var MaybeA = function() { var _ty; return function() { if (!_ty) _ty = _tcomb2.default.maybe(_a.A, "MaybeA"); return _ty; } }();

And of course

    _assert(a, MaybeA, "a");

becomes

    _assert(a, MaybeA(), "a");

[gcanti]

Flow allows for circular dependencies at the type-level. However babel-plugin-tcomb needs to reify those types at the value level so avoiding circular dependencies in the first place seems the best option.

I'm not sure that a lazy definition like that would handle all the use cases

[lwchkg]

Flow allows for circular dependencies at the type-level. However babel-plugin-tcomb needs to reify those types at the value level so avoiding circular dependencies in the first place seems the best option.

Sadly those circular dependencies are not always removable. Consider the case a parent object that owns a few children, and each children has a weak reference to the parent. This is a circular reference, but not a bad programming habit at all.

I'm not sure that a lazy definition like that would handle all the use cases.
No. By adding export b_singleton = new B(null); at the end of b.js, the lazy evaluations will be immediately invoked and still crash. However, declarations alone will not be able to crash the lazy definitions, be it type, function or class.

Anyway, unless we can put the definition of A in another file, we can't really be sure that the definitions will be loaded before it is executed. But I don't think we can do this with babel.