compiled_mirrors 0.1.0

  • Installing
  • Versions
  • 46

Compiled Mirrors

Statically reflecting Dart classes.

Reflection in Dart through dart:mirrors is a powerful tool for building tests and assorted utilities. However, when compiled to JavaScript and run in a browser, mirrors can severely reduce code's performance. In Flutter, mirrors are disabled entirely.

Compiled Mirrors generates a reflection of Dart classes annotated with @compileMirrors. This allows you to do a number of interesting things.

Testing complex classes

My focus has been on using this as a testing utility for evaluating the fields between two complex objects. For example, suppose we have the following class:

class Person {
  final String firstName;
  final String lastName;
  final int age;
  final Location birthplace;
  final Location residence;
  final University almaMater;

  Person(this.firstName, this.lastName, this.gender, this.age,
      this.birthplace, this.residence, this.almaMater);

  factory Person.fromParents(Person mother, Person father) {
    // Make a new person with traits of both parents.

Suppose we want to test the fromParents factory. We'd need to build an expected Person for the results of the test, and an actual Person:

test('fromParents Person factory', () {
  var expected = new Person(/* various fields */);
  var actual = new Person.fromParents(testMother, testFather);

Without an equality definition for this person, we need to test against every field in the Person object:

  expect(actual.firstName, expected.firstName);
  expect(actual.lastName, expected.lastName);
  // boilerplate continues.

Very verbose!

Also, if we decide later on that we want to add a birthDate field to Person, the test will pass even if the factory generates a birthDate we didn't expect! This is a bug waiting to happen.

Mirrored fields

We can avoid this problem with a mirror of the object's fields. If we compile a mirror for the Person object, we can generate an automatically-updating equality test:

test('fromParents Person factory', () {
  var expected = new Person(/* various fields */);
  var actual = new Person.fromParents(testMother, testFather);
  var expectedFields = new Person$CompiledMirror(expected).fields;
  var actualFields = new Person$CompiledMirror(actual).fields;
  for (var fieldName in expectedFields.keys) {
    expect(actualFields[fieldName](), expectedFields[fieldName]());

Much simpler and much more reliable!

Other uses

There are other uses for mirrors. If there's a use case that you'd like a compiled mirror for, please file an issue.

1. Depend on it

Add this to your package's pubspec.yaml file:

  compiled_mirrors: "^0.1.0"

2. Install it

You can install packages from the command line:

with pub:

$ pub get

with Flutter:

$ flutter packages get

Alternatively, your editor might support pub get or packages get. Check the docs for your editor to learn more.

3. Import it

Now in your Dart code, you can use:

import 'package:compiled_mirrors/compiled_mirrors.dart';
Version Uploaded Documentation Archive
0.1.0 Mar 28, 2017 Go to the documentation of compiled_mirrors 0.1.0 Download compiled_mirrors 0.1.0 archive


This feature is new.
We welcome feedback.
More details: scoring.

We analyzed this package, and provided a score, details, and suggestions below.

  • completed on Feb 3, 2018
  • Dart: 2.0.0-dev.20.0
  • pana: 0.10.1


Describes how popular the package is relative to other packages. [more]
0 / 100
Code health derived from static analysis. [more]
100 / 100
Reflects how tidy and up-to-date the package is. [more]
80 / 100
Overall score:
Weighted score of the above. [more]


Detected platforms: Flutter, web, other

No platform restriction found in primary library package:compiled_mirrors/compiled_mirrors.dart.


  • Maintain

    Changelog entries help clients to follow the progress in your code.

  • The description is too short.

    Add more detail about the package, what it does and what is its target use case. Try to write at least 60 characters.

  • Package is pre-v1 release.

    While there is nothing inherently wrong with versions of 0.*.*, it usually means that the author is still experimenting with the general direction API.

  • Enable strong mode analysis.

    Strong mode helps you to detect bugs and potential issues earlier.Start your analysis_options.yaml file with the following:

      strong-mode: true


Package Constraint Resolved Available
Direct dependencies
analyzer >=0.29.9 <0.30.0 0.29.11 0.31.0+1
build >=0.7.2 <0.8.0 0.7.3 0.12.0+1
build_runner >=0.3.0 <0.4.0 0.3.0+1 0.7.9
build_test >=0.4.0 <0.6.0 0.4.1 0.10.0
quiver >=0.24.0 <0.25.0 0.24.0 0.28.0
Transitive dependencies
args 0.13.7 1.3.0
async 1.13.3 2.0.3
barback 0.15.2+14
boolean_selector 1.0.2
build_barback 0.1.1 0.5.0+3
charcode 1.1.1
cli_util 0.0.1+2 0.1.2+1
code_transformers 0.5.1+3 0.5.1+4
collection 1.14.5
convert 2.0.1
crypto 2.0.2+1
csslib 0.14.1
glob 1.1.5
html 0.13.2+2
http 0.11.3+16
http_multi_server 2.0.4
http_parser 3.1.1
io 0.3.2+1
isolate 1.1.0
js 0.6.1
logging 0.11.3+1
matcher 0.12.1+4
meta 1.1.2
mime 0.9.6
multi_server_socket 1.0.1
node_preamble 1.4.0
package_config 1.0.3
package_resolver 1.0.2
path 1.5.1
plugin 0.2.0+2
pool 1.3.4
pub_semver 1.3.2
shelf 0.6.8 0.7.2
shelf_packages_handler 1.0.3
shelf_static 0.2.7
shelf_web_socket 0.2.2
source_map_stack_trace 1.1.4
source_maps 0.10.4
source_span 1.4.0
stack_trace 1.9.1
stream_channel 1.6.3
string_scanner 1.0.2
term_glyph 1.0.0
typed_data 1.1.5
utf 0.9.0+4
watcher 0.9.7+7
web_socket_channel 1.0.6
when 0.2.0
which 0.1.3
yaml 2.1.13
Dev dependencies
test any 0.12.30+1