Failed assert.isInstance() checks due to namespacing of bundled classes

[jeffposnick]

Library Affected:
sw-routing

There are some places in sw-routing where assert.isInstance() is used to check whether a parameter is of the correct class, e.g. assert.isInstance({route}, Route);.

I've seen situations where this fails when the class in question (here it's Route, but it might apply to other classes as well) is defined in multiple top-level modules, like in both sw-routing and sw-lib. Certain bundlers will rename what would otherwise be conflicting class names, so you end up with Route$1 and Route$2, and as far as the assertion can tell, those are two different classes.

The real fix is probably to promote a way of telling the bundler that Route from each of those modules is actually the same symbol.

A more tactical fix might be to change the assert.isInstance() check so that it looked at the string version of the class names, and only required equality up until you reach a '$' character.

A brute-force fix would be to drop the assertion entirely.

[addyosmani]

Certain bundlers will rename what would otherwise be conflicting class names, so you end up with Route$1 and Route$2, and as far as the assertion can tell, those are two different classes.

Is this happening with Rollup?

[jeffposnick]

I'm fairly sure Rollup is adding in the namespaces, yes. But it's doing so in response to us passing in sources that it can't safely assume are the same underlying classes.