search

dart-archive / polymer-dart

Polymer support for Dart
https://pub.dartlang.org/packages/polymer
BSD 3-Clause "New" or "Revised" License
181 stars 33 forks source link

Dart development compiler support #721

Open johnpryan opened 7 years ago

johnpryan commented 7 years ago

Description

Steps to Reproduce

Some (general) steps to reproduce are:

  1. Create a polymer.dart project
  2. enable strong_mode in analysis_options.yaml
  3. run dartdevc
  4. observe strong-mode errors
jakemac53 commented 7 years ago

There is a lot more involved here than just strong mode errors, as I don't think that the dev compiler supports reflection to the degree that un-transformed polymer apps would need it.

johnpryan commented 7 years ago

thanks for the quick response - are you saying there there might be a solution involving running the transformers up-front?

jakemac53 commented 7 years ago

The real solution here is to migrate polymer and all of its related transformers over to package:build (or source_gen, which uses build). Ultimately I think this comes down to some work in package:initialize and package:reflectable, which rewrite their own sources in a transformer (see https://github.com/dart-lang/initialize/blob/master/pubspec.yaml#L22 and https://github.com/dart-lang/reflectable/blob/master/reflectable/pubspec.yaml#L24). This is how they switch between reflective/codegen modes, and is not possible in package:build since rewriting sources is banned.

Angular solves this with a separate entrypoint that you use for bootstrapping the app (angular2/platform/browser[_static].dart). If you are doing codegen always you can just import the static one directly instead of relying on the transformer. For package:initialize the same approach can easily be taken, but I think its more difficult for package:reflectable.

jakemac53 commented 7 years ago

The alternative using transformers is you have to run pub build and then dartdevc each as part of your dev cycle, which would be quite painful (and slow).

jakemac53 commented 7 years ago

cc @eernstg for reflectable

eernstg commented 7 years ago

I haven't been working on reflectable for a while (the time just melts away as you do other things ;-), but I want to take the experiment using the build package and make that available in the published version of reflectable. The main issue is organizational: A naive approach to doing this will create a lot of duplicate files (for instance, because the import structure of a test using build is different from the import structure of a test using a transformer, and the main function needs to contain an extra statement in the version using build, etc). So maybe we should just accept the massive redundancy (and write a script to compare the copies and ensure that they stay pseudo-identical as they should). I definitely want to make this happen real soon now (finally..).

On Fri, Nov 18, 2016 at 6:41 PM, Jacob MacDonald notifications@github.com wrote:

cc @eernstg https://github.com/eernstg

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dart-lang/polymer-dart/issues/721#issuecomment-261593642, or mute the thread https://github.com/notifications/unsubscribe-auth/AJKXUlfHU0T9n-_4zZoeUGa9zsewrP-nks5q_eMygaJpZM4K2Air .

Erik Ernst - Google Danmark ApS Skt Petri Passage 5, 2 sal, 1165 København K, Denmark CVR no. 28866984

jakemac53 commented 7 years ago

Ok, I can't remember the specifics @eernstg but Ideally we wouldn't have to actually change any imports outside of the entry point file. I think in the reflectable case that would require some additional boilerplate in the entrypoint even for reflective apps though (you would have to register some reflective implementation, which you would import via reflectable_mirrors.dart or something). Is that an option do you think? Overall it would probably make things a lot more sane (and this is what polymer/web_components/initialize do).

eernstg commented 7 years ago

I still haven't had an opportunity to spend time on reflectable, but I just noticed this remark:

are you saying there there might be a solution involving running the transformers up-front?

You should be able to use arbitrary transformers by writing your code in a package, specifying the transformers in 'pubspec.yaml', running them via pub build --mode=debug the_relevant_directory, and then continue processing the files in $PACKAGE_ROOT/build/the_relevant_directory, e.g., compiling them with dartdevc. That may be very inconvenient comparing to other workflows, but it should in principle do the job.

Hecatoncheir commented 7 years ago

Will the polymer support dartdevc in the future?

dam0vm3nt commented 7 years ago

it's already supporiting it : https://pub.dartlang.org/packages/polymerize