make ember-cli-mirage a thinner wrapper for miragejs
cah-brian-gantzler opened this issue · 15 comments
Given that most the login has been extracted to miragejs, remove the re-exports to make it clearer what functionality is being provided by this addon. This would also help consumers in knowing if an issue should be posted here or on the miragejs repo.
This would be a breaking change for the following:
- Consumers would have to change the following imports from
ember-cli-miragetomiragejs- Model, belongsTo, hasMany for any models they created. Users of ember data having the models being created for them would not have to do anything for those models as this addons imports would be adjusted
- imports for the shorthands (base, delete, get, head, post, put). Handlers are defined on the route hook and not imported directly in code. I can not see where this is even mentioned in the guides as a possibility.
- factory, trait, ActiveModelSerializer, JSONApiSerilaizer, serializer and serializerRegistry
- Schema, polymorphic-collection, assert, association, db, dbCollection, identityManager, response, routeHandler
- Utils extend, camelize, dasherize, underscore, capitalize, isAssociation, referenceSort, uuid
- inflector (singularize, pluralize)
- The main server config would be updated to use the makeServer version. This would bring it more in-line with the miragejs documentation for implementing a server.
- The opt in setting to create ember data models would be removed. Its replacement would be clearer in the above defining of the server.
Updating all the docs for any references to the import changes and removing whole sections of the docs that do not pertain to ember-cli-mirage functionality but instead are now just rehashes of the miragejs docs. https://www.ember-cli-mirage.com/docs/route-handlers/functions for example is https://miragejs.com/docs/main-concepts/route-handlers/
As you can see there is a large surface area being re-exported by ember-cli-mirage with many of the re-exports from miragejs just giving better names to what is probably private classes that miragejs may be exporting just for ember-cli-mirage compatibility. Removing these would eventually help miragejs. For example Schema is export { _ormSchema as default } from 'miragejs';
While this is a breaking change, the change is simple, in most cases just the import. Before doing this much work though wanted to get some buy-in. In previous conversations with @samselikoff this seemed like a good idea.
Tbh I think the better move would be to deprecate this addon and add guides to miragejs.com on how to set up dev + testing in an Ember project. It shouldn't be too hard these days with npm imports in Ember.
There is some meat to survive in the addon. A little bit of the setupMirage and the emberDataModels (I use the added emberSerializers of course as well). So if a new addon was created that just had those portions of it, yea, most this is now a thin wrapper. Might be easier to create a new addon than to try and pruned the unneeded code from this one.
Actually the more I think about this I will try to put together a new addon and see what it takes to remove ember-cli-mirage from my app while preserving the ember data models generation
ember-cli-mirage is a very known addon name, I am assuming that the reason you would prefer to have another addon stood up in its place is that you would no longer want to maintain this.
I do have an addon running (Learned a little more in how tests fire up in the process). Slowly working through the tests because I have updated all the code to be octane in the tests. Will update you when I get it mostly completed.
I will have to followup with a lot of docs and a github pages site since the ember-cli-docs site would also go away.
I think it's totally ok to keep this 👍 I haven't been actively maintaining for a while now so really it shouldn't be dependent on me. I think the main reasoning would be to nudge ember folks to be able to use the shared mirage resources like the docs on miragejs.com. And for them to just be able to follow those examples. But given there's not a ton of resources to invest it might be best to avoid churn and just keep things as they are!
Totally happy whichever direction you want to go.
I have a new addon working and all the tests passing with the exception of the fastboot ones. I am not experienced in fastboot and have no idea what the problem is. Hoping someone will be able to get those running in a PR eventually.
I had a few things not working, and eventually it turned out you have to do .extend, the class syntax did not work as expected. so
export default class UserModel extends Model {
}
export default class MyRestSerializer extends RestSerializer {
}
does not seem to work the same as
export default Model.extends({
});
export default RestSerializer.extends({
});
Do you happen to know why the objects from mirageJS has to be extended?
We used the extend module from backbone because when we wrote mirage es6 classes weren't out. I had planned to refactor but never got around to it.
In a few moments in my current large application, I removed ember-cli-mirage from the package.json and replaced it with my addon, then changed all the references for ember-cli-mirage to ember-mirage and all my tests in my current application ran. I was able to do this because I was already importing mirageJS for all the items that originate from mirageJS, that just left me to update where I was importing setupMirage, the mirage application serializer and the name in the config/environment.js
If you have not been maintaining this addon I assume @Turbo87 has been, I know I submitted some PRs but I think he has been the one to release them. He hasnt commented on this thread though. I could make a mass update to all the files as a major breaking change or continue with a new addon, would like his input though.
Given the history of the name and it being such a widely used addon, I would think that keeping this name and place would be the better choice. While I do have a complete addon replacement working, there is still work to do in Docs and such. And if someone were to make a couple updates here, the other addon would not really be adopted. That being said, who is maintaining this addon and making new releases. Should this addon be considered for ember adopted addons?
I stopped maintaining it so yes, it probably should!
Are you able to reach out and make the transition https://github.com/adopted-ember-addons/program-guidelines
👋 @samselikoff totally up to help get this maintained
@MelSumner added! Sorry about the delay, let me know if I can be of any other help!
Progress towards this is currently underway