cah-brian-gantzler · February 10, 2022 14:25
diff --git a/ember-cli-mirage-embroider b/ember-cli-mirage-embroider
 Ember-cli-mirage in an Embroider world

 Way out of my depth here. Will keep this up to date as I learn more.

 What does ember-cli-mirage provide? (now that MirageJS has extracted the core of code)

 1. Allows you to define your models, adapters, fixtures, etc as seperate files via blueprints. It discovers those files and provides them to the make-server in a hash that MirageJS expects
 2. Provides a method to discover all the ED models and create the mirageJS definitions needed for the mirageJS createServer. Also now provides same for serializers.
 3. Provides a method to start the server in dev mode`startMirage` and a method to start the server in tests `setupMirage`
 4. Provides a way to include the mirage files in dev mode (auto start the server)or production or only for tests


 How would we do this in an embroider compliant way?

 1. Embroider would prefer you import them directly. In the config.js you could import all the files and build the hash yourself.
  A lot of boilerplate code. We could alter the blueprints that create the files to also add the imports and create the 
  hash much like adding a route does for the router. 
  Currently this is done by https://github.com/miragejs/ember-cli-mirage/blob/master/addon/utils/read-modules.js

 2. TODO: Currently do not know how to do this in an embroider compliant way. Manually could import each ED model 
  (more boilerplate) and provide an array to the util that spits out the mirageJS definitions. 
  Currently this is done by https://github.com/miragejs/ember-cli-mirage/blob/master/addon/ember-data.js#L65
  Could pass this array in rather than call `getDsModels`. Could also be a codemod that you would run that would
  discover the models and write the file that would be the boilerplate imports and other needed code. 

 3. This would be handled in much the same way as it is now, only I think you would import the `mirage/config.js` and pass
   it to one of these methods. Every test file would have to include the `mirage/config.js` but it would give you the ability 
   configure the server differently for each test in a much clearer way. You actually can do this now, but its very confusing
   and not documented.

 4. If the `mirage/config.js` is imported and passed (and the config contains the imports to the `mirage` directory),
   as mentioned in point , I think this takes care of itself through tree shaking. 

 4a. There is a suggestion of using the exports property of webpack. Exports can be conditional
 (see https://webpack.js.org/guides/package-exports/#conditional-syntax) While there is a condition of `development`, I 
 do not see one for `testing`. Its hopeful that embroider may already expose a condition that would satisfy.
	Ember-cli-mirage in an Embroider world

	Way out of my depth here. Will keep this up to date as I learn more.

	What does ember-cli-mirage provide? (now that MirageJS has extracted the core of code)

	1. Allows you to define your models, adapters, fixtures, etc as seperate files via blueprints. It discovers those files and provides them to the make-server in a hash that MirageJS expects
	2. Provides a method to discover all the ED models and create the mirageJS definitions needed for the mirageJS createServer. Also now provides same for serializers.
	3. Provides a method to start the server in dev mode`startMirage` and a method to start the server in tests `setupMirage`
	4. Provides a way to include the mirage files in dev mode (auto start the server)or production or only for tests


	How would we do this in an embroider compliant way?

	1. Embroider would prefer you import them directly. In the config.js you could import all the files and build the hash yourself.
	A lot of boilerplate code. We could alter the blueprints that create the files to also add the imports and create the
	hash much like adding a route does for the router.
	Currently this is done by https://github.com/miragejs/ember-cli-mirage/blob/master/addon/utils/read-modules.js

	2. TODO: Currently do not know how to do this in an embroider compliant way. Manually could import each ED model
	(more boilerplate) and provide an array to the util that spits out the mirageJS definitions.
	Currently this is done by https://github.com/miragejs/ember-cli-mirage/blob/master/addon/ember-data.js#L65
	Could pass this array in rather than call `getDsModels`. Could also be a codemod that you would run that would
	discover the models and write the file that would be the boilerplate imports and other needed code.

	3. This would be handled in much the same way as it is now, only I think you would import the `mirage/config.js` and pass
	it to one of these methods. Every test file would have to include the `mirage/config.js` but it would give you the ability
	configure the server differently for each test in a much clearer way. You actually can do this now, but its very confusing
	and not documented.

	4. If the `mirage/config.js` is imported and passed (and the config contains the imports to the `mirage` directory),
	as mentioned in point , I think this takes care of itself through tree shaking.

	4a. There is a suggestion of using the exports property of webpack. Exports can be conditional
	(see https://webpack.js.org/guides/package-exports/#conditional-syntax) While there is a condition of `development`, I
	do not see one for `testing`. Its hopeful that embroider may already expose a condition that would satisfy.
No results found