Dart development compiler support

[johnpryan]

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]

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]

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

[jakemac53]

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]

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]

cc @eernstg for reflectable

[eernstg]

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
#721 (comment),
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]

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]

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]

Will the polymer support dartdevc in the future?

[dam0vm3nt]

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