miragejs/ember-cli-mirage

Public API for addons to determine if mirage files are included in the buld

bendemboski opened this issue · 0 comments

Some addons export code from addon/ that imports code from mirage, e.g. a route handler function that returns a Response, or mirage model definitions that need to import Model to subclass it, so applications can use them in their mirage setup. A couple of examples are ember-cli-graphql and ember-file-upload. Currently there is not a very safe way to do this because the addon has no good way of knowing if mirage's files are included in the build according to the mirage config or not.

Before embroider, this has kind of flown below the radar because in cases where the mirage code wasn't included in the build, the application obviously wouldn't be starting the mirage server, so none of the routes or models or anything would be required at runtime (even if they are included in the bundle), meaning the code supplied by the addon that would have imports pointing to not-present mirage code would just be inert and never executed, and not cause any problems other than inflating the bundle size. But embroider does more static analysis, and fails if an import can't be resolved, so this now causes a problem, and any code that imports mirage code must be excluded from the build whenever mirage is excluded from the build, whether it will ultimately be executed at runtime or not.

ember-cli-graphql solves this by replicating mirage's configuration logic, but this doesn't seem like a great solution to apply generally. So, my proposal is to provide a Node.js API that addons can use at build-time to ask ember-cli-mirage if its files will be included in the build.

I can think of several ways to do this:

  1. Make _shouldIncludeFiles() public so addons can just require('ember-cli-mirage').shouldIncludeFiles(). However, then addons have to either make ember-cli-mirage a runtime dependency which seems less than ideal, or handle the case where ember-cli-mirage isn't installed in the consuming application, which isn't difficult practically, but just adds extra complexity.
  2. Have ember-cli-mirage check the config sometime early in the build process and export an environment variable when its files are included in the build that other addons can check. That way if ember-cli-mirage is either not installed at all, or installed but not including its files, the environment variable would not be set and addons would know to exclude their mirage-dependent files. This would probably work, but using the environment this way rather than some explicit ember-cli mechanism seems kinda kludgy.
  3. Have ember-cli-mirage call _shouldIncludeFiles() in its included() hook and write the result back to the ember-cli-mirage object in the config (the same place it reads its enabled and other values). That way addons could use the after key in the ember-addon section of package.json to ensure their hooks are called after ember-cli-mirage's, and then they can look in the configuration object, just like mirage does, to determine whether to add mirage-dependent files, except there will be a flag explicitly indicating whether to include mirage files or not.

(3) seems like the right approach to me, so I'll be opening a PR proposing that change shortly.