Skip to content
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

Open
bendemboski opened this issue Apr 18, 2021 · 0 comments · May be fixed by #2167
Open

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

bendemboski opened this issue Apr 18, 2021 · 0 comments · May be fixed by #2167

Comments

@bendemboski
Copy link
Collaborator

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.

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant