Open LucasSloan opened 6 years ago
I suggest we put this one on the back burner until we get more compelling use cases.
My expectation would be that it is very common to have code that's goog.provide()d in a goog.module. All protos and most of the Closure standard library still use goog.provide. OTOH I have no idea how common it is to have those appear in exported signatures.
Is this fixed by #591?
No, this bug is a known limitation with that PR.
Just found one such case in the wild, so this is no longer purely hypothetical.
reopening as this was rolledback
A goog.provide file:
Produces this .d.ts:
A goog.module file:
Produces this .d.ts:
The goog.provide file generates the namespace
ಠ_ಠ.clutz.goog
, while the goog.module generates the namespaceಠ_ಠ.clutz.module$exports$goog$example
.A goog.module file could require
goog.example
:In incremental mode, Clutz doesn't know if
goog.example
is from a goog.provide file or a goog.module file, so Clutz don't know to emitಠ_ಠ.clutz.goog
orಠ_ಠ.clutz.module$exports$goog$example
.The two styles of namespace declaration need to be united, so incremental mode doesn't need to know about the style of its dependencies.