-
Notifications
You must be signed in to change notification settings - Fork 440
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Public API for addons to determine if mirage files are included in the buld #2166
Comments
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. Fixes miragejs#2166
This was referenced Apr 18, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: