Closed scottrobertson closed 9 years ago
That's kind of the reverse of what's happened in 3.0.
We're now wrapping faker in closures to be super fancy and customizable: https://github.com/thephpleague/factory-muffin/tree/master/src/Faker.
Yeah, just trying to decide if we really need to do that or not.
Well, to me, that's an important feature of factory muffin.
It is, but there are alternatives to Faker that other people may want to use. Which currently, they can, but they still are required to download/install Faker.
How about we move the faker stuff to a new repo for 3.0?
Actually, moving the faker stuff would be a really good plan, and would work really easily since it's already decoupled from the generators in 3.0.
What repo name could we have @scottrobertson?
factory-muffin-faker
perhaps? That would match what flysystem has done in terms of naming.
@philsturgeon Is it possible for you to create a factory-muffin-faker
repo so we can move out https://github.com/thephpleague/factory-muffin/tree/master/src/Faker to it.
Also, we won't be needing a dedicated subdomain for this, just like flysystem doesn't.
I don't know if you will have to deal with setting up travis/packagist too, because I doubt I have permission to do it.
@GrahamCampbell I have set up the repo and added this team to it. You should all have admin permissions over there.
Good job all round!
Thanks. Could you disable the wiki on it please @philsturgeon. I don't seem to have access to the settings.
I can't remember if we have discussed this before or not, but i really think we should totally decouple faker from FactoryMuffin. The only reason it was coupled before was because factories were defined as arrays in classes, so we could not use the faker library directly.
The only "magic" generators that we should have is the one to create another factory.
If people wish to use Faker, they can load it in, and use it directly.