Error running polymer dart component tests

[dcf417]

I'm having trouble getting any of my Polymer Dart tests to run due to the following error that appears after I run pub run test --pub-serve=8081 -p chrome

00:18 +1 -2: compiling test\markdone_test.dart Failed to load "test\markdone_test.dart": Reflecting on type 'TodoInput' without capability dart:_internal wrapException

TodoInput is one of the Polymer Dart components for this project, but I've gotten the same error on other projects I have tried testing.

I checked my pubspec.lock versions for changes, and I noticed that reflectable was upgraded to 0.5.3 recently. I switched back to 0.5.2 and everything was working fine after that.

[zoechi]

Just for reference http://stackoverflow.com/questions/36159144/error-testing-polymer-dart-components

[jakemac53]

I just tried running the polymer dart tests today and they are experiencing the same error, presumably something breaking changed in reflectable cc @eernstg? Or possibly the analyzer?

[jakemac53]

Confirmed that fixing reflectable to 0.5.2 fixes the issue (although this also forces you back to analyzer 0.27.1 and code_transformers 0.4.0 so its hard to say exactly where the issue is).

[jakemac53]

fwiw, I am also getting a lot of warnings like this in pub serve now:

[Warning from Reflectable on polymer|test/src/common/behavior_composition_test.bootstrap.initialize.dart with input polymer|lib/src/common/js_proxy.dart]:
line 68, column 1 of package:polymer/src/common/js_proxy.dart: This reflector does not match anything
class JsProxyReflectable extends Reflectable {

[eernstg]

I don't know exactly what your code looks like, but looking at https://github.com/dart-lang/sample-todomvc-polymer/search?utf8=%E2%9C%93&q=TodoInput I can see a class TodoInput which is a subtype of PolymerMixin, which has the annotation @jsProxyReflectable, which has a SubtypeQuantifyCapability.

This means that JsProxyReflectable should match PolymerMixin via its own metadata (so we should not get the 'does not match anything' warning), and JsProxyReflectable should also match TodoInput because it is a subtype of PolymerMixin (so we shouldn't get the exception due to 'Reflecting .. without capability').

Does your code omit any of these connections? If they are all there then TodoInput should certainly be covered (that is, it's a bug that involves reflectable if it is not covered), and if any of them are missing then we have a reason why it should not be covered (and something outside reflectable should be adjusted in order for TodoInput to be covered).

I found these connections using a plain 'sample-todomvc-polymer', and I can see that it uses polymer 1.0.0-rc.16, reflectable 0.5.2, code_transformers 0.4.0, analyzer 0.27.1. So it's not surprising that all the connections are in place, because this is also the case that you report is working.

However, I cannot reproduce the reported problem by switching to 0.5.3 etc: When I fetch 'sample-todomvc-polymer', go to e020c19ffde543360d2258a8d8a96a4df422ed4e (which is the most recent commit at this point), adjust 'pubspec.yaml' to use polymer 1.0.0-rc.15 (such that it uses reflectable 0.5.3, code_transformers 0.4.1, analyzer 0.27.2), I still get a class mirror for TodoInput, i.e., I cannot reproduce the problem you describe (as expected, I also do not get any 'This reflector does not match anything' warnings).

[jakemac53]

Interestingly I cannot reproduce it on the TodoMvc sample either, although it does happen in the polymer tests themselves? In order to repro you can checkout the polymer repo (this one), and then do the following:

• edit the pubspec.yaml to allow reflectable 0.5.3
• run pub serve test
• run pub run test -pdartium --pub-serve=8080

[eernstg]

OK, it took some experiments to be able to dive into that setup and see anything useful. But at this point I can get the 'This reflector does not match anything' warnings, and I can see that we get null when we try to evaluate metadata (which is the reason why we don't detect that PolymerMixin should be covered because it has @jsProxyReflectable as metadata). I'm not sure why that happens in this context (but there is a certain amount of deja vu in the air ;-).

However, it's getting late at this time and I'll have to go. I'll return to the issue when I get back after the Easter days.

[eernstg]

The reflectable commit https://github.com/dart-lang/reflectable/commit/3a3b23a7ec642283745bf1cf424495099bf323e1 may help here:

The problem associated with 'This reflector does not match anything' was resolved by adding constant resolution in one place where it was missing (namely, for metadata), and by avoiding a level of caching which was unsound because the underlying data can get flushed.

We plan to publish this and a few other improvements as reflectable 0.5.4 very soon.

[jakemac53]

I have confirmed that all the polymer tests pass with the latest reflectable. Let me know once that is published and I can release a new version with less strict version constraints. Thanks!

[eernstg]

Great, thanks! The version to publish is under review now, response expected tomorrow.

[eernstg]

Got it: https://pub.dartlang.org/packages/reflectable now says '0.5.4'.

[zoechi]

Can the polymer-dart work with a newer reflectable?

A user of my bwu_polymer_routing is blocked because it uses di which requires analyzer ^0.27.2 which requires reflectable 0.5.4 The user reported that Dartium "aw snap"s when bwu_polymer_routing is added to the dependencies. I suspect the issue is that he gets lots of outdated dependencies when bwu_polymer_routing is added to pubspec.yaml. A version of di that is compatible with polymer-dart requires an older analyzer which drags all dependencies down.

[jakemac53]

Working on this now