You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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.
The text was updated successfully, but these errors were encountered:
bendemboski
added a commit
to bendemboski/ember-cli-mirage
that referenced
this issue
Apr 18, 2021
Implement a public API (using the environment config) for addons to determine if mirage's files are included in the build, so they can decide whether to include any mirage-dependent files.
Fixesmiragejs#2166
Some addons export code from
addon/
that imports code from mirage, e.g. a route handler function that returns aResponse
, or mirage model definitions that need to importModel
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 askember-cli-mirage
if its files will be included in the build.I can think of several ways to do this:
require('ember-cli-mirage').shouldIncludeFiles()
. However, then addons have to either makeember-cli-mirage
a runtime dependency which seems less than ideal, or handle the case whereember-cli-mirage
isn't installed in the consuming application, which isn't difficult practically, but just adds extra complexity.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 ifember-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 explicitember-cli
mechanism seems kinda kludgy.ember-cli-mirage
call_shouldIncludeFiles()
in itsincluded()
hook and write the result back to theember-cli-mirage
object in the config (the same place it reads itsenabled
and other values). That way addons could use theafter
key in theember-addon
section ofpackage.json
to ensure their hooks are called afterember-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.
The text was updated successfully, but these errors were encountered: