v0.4.8

This release is all about getting 🛁 squeaky clean, and fixing many outstanding bugs in prep for a v1.0!

There should be no upgrade steps for your apps.

• Shorthands now support polymorphic associations
• Many bug fixes that shouldn't affect your apps. (One significant change of undocumented/untested behavior was that the serializeIds property of ActiveModelSerializer and RestSerializer now defaults to always).

Drop by #ec-mirage if you have any trouble upgrading!

v0.4.7

• Better console log messages. Console messages are grouped, and now show request and response.
• Better association() helper. The association() helper used in Factories will no longer create a belongsTo association if one is being passed in at the time of creation.
• Adds .none() method to Collections.
• Bugfix: polymorphic relationships.
• Bugfix: smarter data linkage when including by query params.

v0.4.6

Server routes (server.post('foo')) now return pretender handlers. #1309

v0.4.5

Fix a bug that came up when using Mirage in addons: Attempting to watch missing directory

v0.4.4

• Allow HEAD requests to be passthrough'd
• Bug fixes (#1305, #1289)

v0.4.3

• Improve detection of model inverses
• Fix a bug related to serializing responsese that are both sideloaded and embedded

v0.4.2

• Adds support for new style (RFC232/RFC268) tests
• Parts of Mirage's factory layer that create data are faster
• Serializers support coalesced IDs
• Ensure JSONAPISerializer supports include as function
• Add support for options mocking

How it works in different types of tests

• Old-style non-acceptance tests: mirage will not automatically start, and can still be manually started using the startMirage() import from <app>/initializers/ember-cli-mirage.
• Old-style acceptance tests: mirage will still be started before each test by <app>/initializers/ember-cli-mirage and shut down by the code that ember-cli-mirage's blueprint adds to destroyApp().
• RFC232 and RFC268 tests: <app>/initializers/ember-cli-mirage will detect that it's an RFC232/RFC268 test and not start the mirage server automatically in the way that is problematic for the new tests, and since the new tests don't use destroyApp(), it's not at play either. So there are two options:
  • In each test that needs it, call setupMirageTest(), which will register beforeEach/afterEach hooks to set up and shut down the mirage server and make it accessible via this.server (and also the server global).
  • Set autostart: true in your ember-cli-mirage config object in config/environment which will cause an instance initializer to run before each test (every RFC232/RFC268 test, not just "acceptance" (application) tests) to start mirage and set it as this.server on the test context (and also the server global), and also register and create a singleton that, when destroyed during app shutdown, will shut down the mirage server.

Upgrade path

This is not a breaking change -- existing tests will run just as they are. Furthermore, new and old tests can live side by side and work properly with mirage if the right setup is done, so you are not forced to migrate your whole suite all at once. As you migrate tests, you have two options:

• As non-acceptance tests are migrated, delete the manual starting/stopping of mirage in beforeEach/afterEach and replace it with a call to setupMirageTest() and continue using this.server. As acceptance tests are migrated, add a call to setupMirageTest() and optionally switch from using the server global to using this.server.
• Set autostart: true in config/environment, and then as non-acceptance tests are migrated, just delete the manual starting/stopping of the mirage server and continue using this.server. As acceptance tests are migrated, no changes are necessary, but users can optionally switch from using the server global to using this.server.

v0.4.1

Update notes: none

Changes:

• [BREAKING CHANGE]#1263 Mirage's initializer was renamed from ember-cli-mirage to ember-cli-mirage-config. This was unintentional and has been reverted in master.
• [BUGFIX]#1217 Make tracking pretender requests configurable after it was hardcoded false #1137. @patrickjholloway
• General upgrade to use async/await in tests @geekygrappler
• [ENHANCEMENT]#1203 pass singular model name to resource helper @geekygrappler
• [ENHANCEMENT]#1199 upgrade to new QUnit testing API @Turbo87

v0.4.0

Update notes:

• There is one primary change in 0.4 that could break your 0.3 app.

  In 0.3.x, Mirage's JSONAPISerializer included all related foreign keys whenever serializing a model or collection, even if those relationships were not being included in the payload.

  This actually goes against JSON:API's design. Foreign keys in the payload are known as Resource Linkage and are intended to be used by API clients to link together all resources in a JSON:API compound document. In fact, most server-side JSON:API libraries do not automatically serialize all related foreign keys, and only return linkage data for related resources when they are being included in the current document.

  By including linkage data for every relationship in 0.3, it was easy to develop Ember apps that would work with Mirage but would behave differently when hooked up to a standard JSON:API server. Since Mirage always included linkage data, an Ember app might automatically be able to fetch related resources using the ids from that linkage data plus its knowledge about the API. For example, if a post came back like this:

  // GET /posts/1
  {
    data: {
      type: 'posts',
      id: '1',
      attributes: { ... },
      relationships: {
        author: {
          data: {
            type: 'users',
            id: '1'
          }
        }
      }
    }
  }

  and you forgot to ?include=author in your GET request, Ember Data would potentially use the user:1 foreign key and lazily fetch the author by making a request to GET /authors/1. This is problematic because

  1. This is not how foreign keys are intended to be used
  2. It'd be better to see no data and fix the problem by going back up to your data-loading code and add ?include=author to your GET request, or
  3. If you do want your interface to lazily load the author, use resource links instead of the resource linkage data:

  // GET /posts/1
  {
    data: {
      type: 'posts',
      id: '1',
      attributes: { ... },
      relationships: {
        author: {
          links: {
            related: '/api/users/1'
          }
        }
      }
    }
  }

  Resource links can be defined on Mirage serializers using the links method (though including is likely the far more simpler and common approach to fetching related data).

  So, Mirage 0.4 changed this behavior and by default, the JSONAPISerializer only includes linkage data for relationships that are being included in the current payload (i.e. within the same compound document).

  This behavior is configurable via the alwaysIncludeLinkageData key on your JSONAPISerializers. It is set to false by default, but if you want to opt-in to 0.3 behavior and always include linkage data, set it to true:

  // mirage/serializers/application.js
  import { JSONAPISerializer } from 'ember-cli-mirage';
  
  export default JSONAPISerializer.extend({
    alwaysIncludeLinkageData: true
  });

  If you do this, I would recommend looking closely at how your real server behaves when serializing resources' relationships and whether it uses resource links or resource linkage data, and to update your Mirage code accordingly to give you the most faithful representation of your server.

• Support for Node 0.12 has been explicitly dropped from some of our dependencies

• If you are using a version of Pretender that supports tracking requests, you'll need to enable it in Mirage. This is the first version of Mirage that ships with a version of Pretender that has tracking support, and we disable it by due to the feature’s memory footprint. To enable Pretender’s request tracking, set ENV['ember-cli-mirage'].trackRequests = true.

Special thanks to @Turbo87 and @kellyselden for all their work on this release.

Changes:

• [ENHANCEMENT]#1150 Change default JSONAPI data linkage behavior (reference #1146) @samselikoff
• [BUGFIX]#1148 Foreign key ids were being muted by collection creation @lukemelia
• [BUGFIX]#1078 Ensure #update works on associations @ivanvanderbyl
• [BUGFIX]#1112 Fix query in disassociateAllDepentsFromTarget @omghax
• [BUGFIX]#0176 Fix using association helper in a dasherized factory @ignatius-j
• [ENHANCEMENT]#1138 Unlock and upgrade ember-get-config @dfreeman
• [ENHANCEMENT] #b99717 Serializer blueprint should extend the application serializer @ChrisBarthol
• [ENHANCEMENT]#1187 Use native ES class syntax for base Class.extend @cowboyd
• [ENHANCEMENT]#1137 Bump pretender and disable request tracking in pretender @bekzod
• General enhancements @HeroicEric, @Turbo87, @kellyselden, @bekzod, @timhaines, @wismer, @mixonic, @rwjblue

v0.3.4

Update notes: none

Changes:

• [ENHANCEMENT]#1098 Fix for FastBoot 1.0 @simonihmig
• [ENHANCEMENT]#1102 Extend modelRegexp to match models in pod structure @dguettler
• [ENHANCEMENT]#1096 Fixed existence of relationships.data if links are defined @lancedikson
• [FEATURE]#1110 Expose database in serializer @zinyando
• [FEATURE]#977 adds support for custom identity managers per application and model @jelhan
• General enhancements @samselikoff, @kellyselden, @rwjblue