Thursday, September 25, 2014

Polymer and Angular Dart are Wildly Incompatible


I am desperately trying to get all chapter projects under test in Patterns in Polymer. I have the JavaScript chapters done and am now working through the Dart versions of those same chapters. For most chapters, I already have tests, but sadly one chapter that lacks tests is the Angular.dart chapter. Hopefully I can mostly reuse the approach that I took in the AngularJS version of the chapter, which is admittedly less that great coverage, but infinitely better than what I have currently for the Dart code.

But first I need to get the darn thing to run.

The dependencies in my pubspec.yml are unconstrained:
name: angular_example
dependencies:
  angular: any
  polymer: any
  angular_node_bind: any
dev_dependencies:
  unittest: any
transformers:
- polymer:
    entry_points:
    - web/index.html
    - test/index.html
So the first think I do is a pub upgrade, which works just fine. I am unsure if angular_node_bind, which facilitates double binding of attributes between Polymer and Angular, is strictly necessary anymore, but I will find out.

Next, I update the setup of the web/index.html smoke test page that I have, fire up the server and find that the update needs an update:
[Warning from polymer (Linter) on angular_example|web/index.html]:
line 27, column 7 of web/index.html: definition for Polymer element with tag name "ng-view" not found.
<ng-view>
^^^^^^^^^
[Warning from polymer (Linter) on angular_example|web/index.html]:
line 24, column 3 of web/index.html: To run a polymer application you need to include the following HTML import: <link rel="import" href="packages/polymer/polymer.html">. This will include the common polymer logic needed to boostrap your application. The old style of initializing polymer with boot.js or initPolymer are now deprecated. 
<body>
^^^^^^
Build completed successfully
I will ignore the <ng-view> warning for now. I do wonder if there is a way to tell the linter to ignore certain tags that are under the control of another library—grist for another day (maybe). The other warning is worrisome. I had just moved all of my Polymer.dart elements over to sourcing the packages/web_components/platform.js script and now it seems that Polymer.dart has changed under my feet.

Except it hasn't.

I wonder if this same message is occurring for the chapter projects currently being tested every day (to accumulate new dependencies). This message is not present for any of these chapters, which leads me to check the pubspec.lock file revealing that Polymer.dart is still back at 0.10:
  # ...
  polymer:
    description: polymer
    source: hosted
    version: "0.10.0-pre.12"
It seems that angular_node_bind has not been updated for 4 months, leaving it constrained to an old Polymer version. So I drop it from pubspec.yml, run pub upgrade and find… that the really old version of Polymer is still being installed:
$ pub upgrade
  ....
  polymer 0.10.0-pre.12 (0.15.0 available)
  ...
Yeah, thanks Dart Pub, I know 0.15 is available, why the heck aren't you installing it?!

Hey, there is no need to get angry with pub, it can answer the question if I ask nicely—by upgrading just the problem dependency:
$ pub upgrade polymer
Resolving dependencies... (8.4s)
Incompatible version constraints on browser:
- angular 0.0.8 depends on version >=0.8.7 <0.9.0
- polymer 0.15.0 depends on version >=0.10.0 <0.11.0
Wait... that is a really old version of Angular.dart—it should be up to 0.14 nowadays. What gives pub?
$ pub upgrade angular polymer
Resolving dependencies... (7.9s)
Incompatible version constraints on args:
- angular 0.14.0 depends on version >=0.10.0 <0.11.0
- polymer 0.15.0 depends on version >=0.11.0 <0.13.0
Gosh. Darn. It.

This does not seem like a problem that I am going to solve in one night, but I would still like to have some idea of the extent of the problem. So I fork Angular.dart, clone it locally and hand-edit their pubspec.yaml to include a more recent of args:
name: angular
version: 0.14.0
# ...
dependencies:
  args: '>=0.10.0 <0.12.0'
  # ...
To use this forked Angular.dart repo, I switch the pubspec.yaml in my chapter project code to point to this local package:
name: angular_example
dependencies:
  angular:
    path: /home/chris/repos/angular.dart
  polymer: any
  # angular_node_bind: any
With that, I get:
$ pub upgrade
Resolving dependencies... (21.8s)
Incompatible version constraints on analyzer:
- angular 0.14.0 depends on version >=0.15.0 <0.19.0
- polymer 0.10.0-pre.0 depends on version >=0.12.2 <0.13.0
Bleh. Now I am back to trying to install an old version of Polymer. I explicitly stick with the most recent by pub upgrading the polymer dependency:
$ pub upgrade polymer
Resolving dependencies... (1.6s)
Incompatible version constraints on code_transformers:
- angular 0.14.0 depends on version >=0.1.4+2 <0.2.0
- polymer 0.15.0 depends on version >=0.2.3 <0.3.0
So I need to again hand-edit Angular.dart's pubspec.yaml, after which I find:
$ pub upgrade polymer
Resolving dependencies... (1.7s)
Incompatible version constraints on html5lib:
- angular 0.14.0 depends on version >=0.10.0 <0.11.0
After another hand edit, I am finally able to pub upgrade:
$ pub upgrade polymer
...
* angular 0.14.0 from path /home/chris/repos/angular.dart (was 0.12.0)
...
> polymer 0.15.0 (was 0.10.0-pre.12)
...
In the end I had to change three different dependencies to get the latest Angular.dart and Polymer.dart installed side-by-side:
name: angular
# ... 
dependencies:
  args: '>=0.10.0 <0.12.0'
  # ...
  code_transformers: '>=0.1.4+2 <0.3.0'
  # ...
  html5lib: '>=0.10.0 <0.13.0'
  # ...
That is very much a bummer. It is especially troublesome for the book. Do I pursue this path and attempt to figure out if Angular.dart works with these new dependencies? Or do I stick with the old version of the packages? Neither is particularly appealing, but I will likely start with a limited attempt at working with a dependency augmented version of Angular.dart. I would hope that these two packages will be eventually consistent and dependency augmentation would position me best for that eventual future.

Day #194

3 comments:

  1. The other method is to use dependency_overrides on the offending packages. I find the following works in getting them installed together, but I was trying to get Angular to work in a Polymer Element, which I gave up on after an hour. I haven't tried getting angular to work normally using Polymer elements yet.

    name: angular_polymer
    description: A sample web application
    dependencies:
    angular: '>=0.14.0'
    browser: any
    polymer: ">=0.14.2+1"
    dependency_overrides:
    analyzer: ">=0.15.0"
    args: ">=0.11.0"
    code_transformers: ">=0.2.3"
    html5lib: ">=0.12.0"
    transformers:
    - polymer
    - angular

    I provide this with no guarantees that it will work, other than the install part.

    ReplyDelete
    Replies
    1. Ah, much thanks for the dependency_overrides pointer. I jumped right into “fixing” Angular, but that's far more work than I really want to do. The overrides are a much better approach for what I want to do--especially in the book.

      Delete