I'm not able to launch any Polymer 1.0.0-rc.10 in Dartium

[zoechi]

Bad state: Reflectable has not been initialized. Did you forget to add the main file to the reflectable transformer's entry_points in pubspec.yaml?

0 data (package:reflectable/src/reflectable_transformer_based.dart:164:5)

1 data (package:reflectable/src/reflectable_transformer_based.dart:163:33)

2 ReflectableImpl.reflectType (package:reflectable/src/reflectable_transformer_based.dart:2181:26)

3 declarationsFor (package:polymer/src/common/declarations.dart:30:36)

4 propertyDeclarationsFor (package:polymer/src/common/polymer_descriptor.dart:46:10)

5 _buildPropertiesObject (package:polymer/src/common/polymer_descriptor.dart:54:22)

6 createPolymerDescriptor (package:polymer/src/common/polymer_descriptor.dart:26:19)

7 PolymerRegister.initialize (package:polymer/src/common/polymer_register.dart:19:36)

8 loadInitializers.. (package:initialize/src/static_loader.dart:46:32)

9 _runInitQueue (package:initialize/initialize.dart:35:24)

10 _runInitQueue. (package:initialize/initialize.dart:38:26)

11 _RootZone.runUnary (dart:async/zone.dart:1149)

12 _Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:551)

13 _Future._propagateToListeners (dart:async/future_impl.dart:637)

14 _Future._completeWithValue (dart:async/future_impl.dart:424)

15 _Future._asyncComplete. (dart:async/future_impl.dart:479)

16 _microtaskLoop (dart:async/schedule_microtask.dart:41)

17 _startMicrotaskLoop (dart:async/schedule_microtask.dart:50)

18 _ScheduleImmediateHelper._handleMutation (dart:html:49247)

19 MutationObserver._create. (dart:html:27519)

(anonymous function)

Switching to rc.9 makes it work again.

[eernstg]

The 'Bad state' message you mention is produced by the package reflectable, and this happens when an untransformed program that uses 'package:reflectable/reflectable.dart' is executed from the target directory for the build process (for a file 'web/foo.dart' that would be 'build/web/foo.dart' or a file derived from that by compilation to JavaScript). This usually means that an entry point should be added to 'entry_points', as indicated in the message. But if this happens in a setup where transformation has previously been used successfully it probably means that the transformation fails.

I have just discovered that we have test failures with reflectable: Every test fails, and we have not made any changes to reflectable since we had a state where they all succeeded. I've verified that all the tests are again running successfully if we add a version constraint such that the analyzer version 0.27.1 is used, rather than 0.27.1+1. It looks like 0.27.1+1 reintroduces the problem that forced reflectable to limit the version of the analyzer to 0.26.1+14 for some weeks.

So you may be able to resolve the problem for now by adding the following to your 'pubspec.yaml':

dependency_overrides:
  analyzer: "0.27.1"

[zoechi]

I just tried it but with analyzer 0.27.1 and 0.27.0 I just get another exception which looks like an analyzer issue.

Transform WebComponents on input_decimal_pattern|web/index.html threw error: Class 'LibraryElementImpl' has no instance getter 'node'.

NoSuchMethodError: method not found: 'node'
Receiver: Instance of 'LibraryElementImpl'
Arguments: []
dart:core-patch/object_patch.dart 42 Object._noSuchMethod
dart:core-patch/object_patch.dart 45 Object.noSuchMethod
package:initialize/transformer.dart 240:24 _BootstrapFileBuilder._readAnnotations
package:initialize/transformer.dart 213:5 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 193:5 _BootstrapFileBuilder.run
package:initialize/transformer.dart 35:25 generateBootstrapFile
package:web_components/build/web_components.dart 32:29 generateWebComponentsBootstrap
package:web_components/build/web_components.dart 82:25 WebComponentsTransformer.apply..
dart:async/zone.dart 1149 _RootZone.runUnary
dart:async/future_impl.dart 551 _Future._propagateToListeners.handleValueCallback
dart:async/future_impl.dart 637 _Future._propagateToListeners
dart:async/future_impl.dart 424 _Future._completeWithValue
dart:async/future_impl.dart 479 _Future._asyncComplete.
dart:async/schedule_microtask.dart 41 _microtaskLoop
dart:async/schedule_microtask.dart 50 _startMicrotaskLoop
dart:isolate-patch/isolate_patch.dart 96 _runPendingImmediateCallback
dart:isolate-patch/isolate_patch.dart 149 _RawReceivePortImpl._handleMessage

dart:core Object.noSuchMethod
package:initialize/transformer.dart 240:24 _BootstrapFileBuilder._readAnnotations
package:initialize/transformer.dart 213:5 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 209:7 _BootstrapFileBuilder._readLibraries
package:initialize/transformer.dart 193:5 _BootstrapFileBuilder.run
package:initialize/transformer.dart 35:25 generateBootstrapFile
package:web_components/build/web_components.dart 32:29 generateWebComponentsBootstrap
package:web_components/build/web_components.dart 82:25 WebComponentsTransformer.apply..
[web] GET index.html => Could not find asset input_decimal_pattern|web/index.html.

[eernstg]

We couldn't use 0.27.0 so 0.27.1 is the most relevant version to consider.

The usage of a getter node on LibraryElementImpl is a version skew: Some part of your setup is using the new analyzer in an old way (node was removed in the new version). Did you run pub upgrade to ensure that the version graph is fully recomputed? Does the constraint solving process succeed?

The change from analyzer 0.26.1+14 to 0.27.1 was accompanied by a rather large number of version changes in other packages, so there are many potential sources of conflict.

[zoechi]

I get an error message because of dart-archive/initialize#43, but the pubspec.lock and packages files are updated.

The pubspec.yaml in the reflectable package seems to support 0.27.0

dependencies:
  analyzer: '^0.27.0'

This is why I tried this version as well.

I guess this should be updated then?

[eernstg]

Yes, the published version 0.5.0 of reflectable claims that it depends on analyzer version '^0.27.0'; it was published after a number of iterations where the analyzer would return null for a number of queries (esp. when evaluating the value of constants at compile-time), and 0.27.1 was the first version where that issue was resolved (after 0.26.1+15 where it was introduced). You are right that it would be more correct to use '>=0.27.1 <0.28.0' than '^0.27.0'. Will do that in the next commit of reflectable.

Right now I think the first priority is to find a way to make things work for you and others who depend on the analyzer, directly or indirectly. The obvious remedy would be a 'dependency_overrides' section forcing version 0.27.1 of the analyzer, but given that this creates other problems for you it is not a complete solution (even though it changes test runs from universally failing to universally succeeding for reflectable itself).

I don't have any precise ideas about how the issues you see can be solved right now, but it would be useful to know which file (F) contains the usage of node on a LibraryElementImpl, which package (P) that file belongs to, and which version (V) of that package you are using ('pubspec.lock' should know). Presumably, version V of P should have had a version constraint preventing the new analyzer from being used (because it uses something that the new analyzer doesn't have and therefore it is not compatible with the new analyzer). P would then presumably have to go a similar version switch exercise as several other packages did recently, and a new version V' of P should resolve the problem.

I suspect that the node issue would be present with any version configuration that includes version V of P and any version of the analyzer that matches '^0.27.0', in which case it wouldn't help you much even if reflectable had been working with analyzer 0.27.1+1; you would still need version V' of P.

In any case, the next step would be to make the most recent commit of reflectable on github work, and then the published version. But if there is going to be a hotfix version (say, 0.27.1+2) of the analyzer available later today then maybe it would be better to keep reflectable unchanged, rather than freezing everything at 0.27.1 by inserting a very narrow version constraint into reflectable. So I'd like to avoid inserting an "analyzer version freeze constraint" into reflectable at least for some hours.

[zoechi]

Thanks a lot for investigating and your quick response (as usual 👍 ).
It's not critical for me, I'll just stick with Polymer rc.9 until the issues are fixed, but more and more devs run into this issue and waste some time each, until they figure out it's not yet working.

I'll commit a repo project later.

You are right that it would be more correct to use '>=0.27.1 <0.28.0' than '^0.27.0'.

^0.27.1 would be the same as '>=0.27.1 <0.28.0' AFAIK.

[zoechi]

A repo project https://github.com/bwu-dart-playground/polymer1/tree/master/input_number

[eernstg]

Thanks for the kind words!

If you keep using Polymer rc.9 for now then you won't get the updates associated with analyzer 0.27.* (in particular "the new task model"), and that basically means you'll delay using a lot of new code for a while (the choice implies that you'll stay with analyzer 0.26.1+14, code_transformers 0.2.*, reflectable 0.4.0). That should be a quite well-tested combination of versions.

About ^version: I found the documentation in the mean time (https://www.dartlang.org/tools/pub/dependencies.html), and the wording is '^version means “the range of all versions guaranteed to be backwards compatible with the specified version”' which should allow for anything up to the next major number. So indeed ^0.27.1 is the same thing as '>=0.27.1 <0.28.0'. Until I found that, I was a little worried that it might mean '>=0.27.1 <0.27.2'. ;)

Looking at your stack trace too briefly, I first assumed that '_BootstrapFileBuilder._readAnnotations' would be in generated code, but looking again I can see that it is fact in package initialize. Checking out the version of initialize that uses 0.27.*, that is initialize version 0.6.2, I cannot find any locations in _readAnnotations that calls any method named node. In fact, that whole package only contains the following occurrences of that identifier:

lib/transformer.dart
240:    var node = element.computeNode();
241:    if (node is SimpleIdentifier && node.parent is LibraryIdentifier) {
242:      metaNodes = node.parent.parent.metadata;
243:    } else if (node is ClassDeclaration || node is FunctionDeclaration) {
244:      metaNodes = node.metadata;
266:      _initQueue.addLast(new InitializerData._(node, metaNode));

lib/build/initializer_plugin.dart
80:    var node = pluginData.initializer.targetNode;
88:          'and top level methods. Found $node.');

I don't think that this version of initialize could ever make such a call. Btw, the method computeNode is the new member which plays the role that the getter node used to play.

So does your version actually contain initialize version 0.6.2? If it uses an older version of initialize then it should contain a constraint '<0.27.0' about analyzer, so you should not be able to have such a combination.

[eernstg]

Ah, you wouldn't by any chance have a 'dependency_overrides' section that forces an older version of initialize? That would break the interaction with the analyzer, so basically you couldn't do that unless you would force all the other versions back to "somewhere before analyzer 0.27.0", which is essentially the same thing is as using rc.9. ;-)

[eernstg]

To me it looks like you can fetch initialize version 0.6.2 (I just did "git clone 'https://github.com/dart-lang/initialize.git'"), insert 'dependency_overrides' for 'initialize' on the appropriate local 'path:' and another one saying 'analyzer: 0.27.1', and then pub build at least creates transformed code. That should eliminate the initial "Bad state: Reflectable has not been initialized." problem, and then you might have a working setup based on rc.10.

The point is that 'initialize' 0.6.2 won't work when fetched by pub, but it will work as long as you use a local copy.

[zoechi]

I guess I'll skip that.
What will fix the issue? A new version of the Initialize package?

[jakemac53]

@zoechi can you try deleting your .pub directly and running again? I think there may be some bug related to the other issue about the path dependency which causes the pub upgrade to not fully complete.

[dam0vm3nt]

@jakemac53 tryied it and even if pub get completes (the second time you run it), test are still failing with Bad state ...

[jakemac53]

@dam0vm3nt did you also try fixing analyzer to 0.27.1 with a dependency_override?

[zoechi]

after deleting the .pub directory I get rid of this error.

[dam0vm3nt]

... and I can confirm it works like a charm with 0.27.1

[dam0vm3nt]

To be more precise :

1. remove .pub and pubspec.lock
2. run pub get first time it gives

   • `Error on line 1, column 1 of https://pub.dartlang.org/api/packages/initialize: Invalid description: "test_package" is a relative path, but this isn't a local pubspec.`
     

3. run pub get a second time : everything is ok

[jakemac53]

see dart-lang/pub#1369 for the pub get error

[eernstg]

Reflectable 0.5.1 has been published today. It insists on analyzer 0.27.1, so there should be no need for dependency_overrides. We will (of course) relax this constraint again when possible.

By the way, I still don't understand how pub get can run, conclude that a given set of constraints have no solution, then run again, and then conclude that there is a solution. How do you do that? If solving constraints by brute force works then it might be a whole new business model. ;^)

[zoechi]

The set has does have a solution, thete is just an error message because of a path dependency (looks like a pub bug) but pub still writes the pubspec.lock and .packages file. On the 2nd run it doesn't do anything because everything is up-to-date, hence no error message.

[eernstg]

Aha, so it is indeed because the 2nd run does not run the same checks. Btw, Jacob has reported the 'dev_dependencies' error message about 'path's.

[jakemac53]

This should all be fixed