Here's the original code, before the build step:

library models;

import 'package:polymer/polymer.dart'
show ObservableMixin, observable, bindProperty, notifyProperty;

/// The Item class represents an item in the Todo list.
class Item extends Object with ObservableMixin {
  @­observable String text = '';
  @­observable bool done = false;

  Item({this.text: '', this.done: false}) {
    // Monitor the done boolean to add/remove done class.
    bindProperty(this, const Symbol('done'),
        () => notifyProperty(this, const Symbol('doneClass')));
  }

  // Check if item text is empty.
  bool get isEmpty => text.isEmpty;

  // Apply a done class for completed items.
  String get doneClass => done ? 'done' : '';
}

I think the issue is: the code has an import with a show. But the build step is introducing a new name that isn't included in the original show, and the build step isn't adding the new name (ChangeNotifierMixin) to the show.

Yup, if I remove the show statements from my original code, the generated code in out/ works.

Added Library-PolymerBuild label.

Bumping to high.

Removed Priority-Unassigned label.
Added Priority-High label.

Sadness. We used to add our own import with prefix, to be safe from this kind of issue. Not sure what happened.

Added Accepted label.

Removed Library-PolymerBuild label.
Added Library-Observe label.

Thanks for verifying!

Added this to the M8 milestone.

for now the workaround is to use wildcard imports. we do want to fix but can happen after M8

Removed this from the M8 milestone.
Added this to the Later milestone.

Issue #14509 has been merged into this issue.

Ugh. No idea how to fix this yet.

The @­observable transformation is local right now. It doesn't need to affect the rest of your file. It doesn't mess up line numbers and it doesn't care if your code is in a library or part.

If we need to add an import, then suddenly we've got to know if we're in a library/part, and if it's a part, we need add the import to the main file. Which is not easy with barback transformers (would've been relatively easy in our old compiler. Doh!)

One idea is to change the transform ... instead of replacing the base class with ChangeNotifier, just override some methods to turn the dirty-checking impl into a no-op. But, I'm not sure how smart dart2js is in this case, in other words: can it kill the dirty-check code?

Set owner to @jmesserly.
Added Started label.

Removed this from the Later milestone.
Added this to the M9 milestone.

Removed this from the M9 milestone.
Added this to the 1.1 milestone.

Issue #15095 has been merged into this issue.

Removed this from the 1.1 milestone.
Added this to the 1.2 milestone.

Issue #16555 has been merged into this issue.

Ah, I knew this sounded familiar. Thanks for de-duping. I have this starred.

Removed Library-Observe label.
Added Pkg-Observe label.

unfortunately, no progress here. Maybe the answer is to ditch the @­observable transform for now & stick with dirty-checking similar to Angular.

Added Accepted label.

Alternatively, we could use the resolver for this. Now that we are using the analyzer in transformers for polymer, I think we can start using it here too. We would apply this on libraries rather than files, though. We can also resolve @­observable and remove the special handling we have for @­published.

This issue has been moved to dart-archive/observe#44.