Rename 'Show' group to 'Entertainment' and add new provider #647
Conversation
panilya
force-pushed
the
entertainment-fakers
branch
from
cdff6cc
to
4617712
Compare
Codecov Report
@@ Coverage Diff @@
## main #647 +/- ##
============================================
- Coverage 92.77% 92.67% -0.11%
- Complexity 2623 2627 +4
============================================
Files 281 282 +1
Lines 5396 5403 +7
Branches 589 589
============================================
+ Hits 5006 5007 +1
- Misses 240 244 +4
- Partials 150 152 +2
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
|
Why do we need to rename it the third time? |
|
Because of the books, there's no sense in adding a |
|
i would rather follow similar category structure and naming as for https://github.com/faker-ruby/faker |
|
Yeah, but a lot of books have movie interpretations, in this case, where should that provider belong? |
|
if a book appeared first then it should be in books it looks other faker follow the similar rule |
I don't think the ruby fake makes much sense, and nobody will switch from Ruby to Java. Besides, the package names are mostly hidden from our users anyway, so I don't see much of an issue here. |
|
the issue is that initially it was called
In fact there is not only package name, also an interface name. |
|
I don't doubt we have to do a few more renames when we move some of the base providers to the right package. For example, we have providers related to an author. An entertainment package would be okay for that maybe, but not movies nor shows. |
With |
Fair enough, but we could also consider moving videogames to entertainment. Not sure if it deserves its own specific package. |
|
I would rather continue splitting providers than merging them. |
|
For me, there are two ways:
|
yes it would be a better approach. However it does not make a big sense to extract something in a group of less than 5 items or something like that |
|
The idea was to one day split the faker into multiple modules. I think it would be a bit silly to have a module with 5 authors, though we could always bundle multiple packages into 1 module. So, I think it doesn't really matter how we organize things. It doesn't affect the API, so I'm fine either way, as in, faker-enterfainment could contain books, tv shows, games, movies, etc, while faker-core/ base contains some number, boolean and perhaps person data. On the other hand, I'm not really sure what problem we're solving by splitting things, I've never heard of a real problem the way the faker is currently set up. |
|
If the project follows semver then a change such as this is breaking which would make the next release 2.0.0. (Since users would have to adapt their code to new reorganized providers.) |
|
I don't see that. There is no import of these packages, the recommended way to use the faker is : faker.provider.property, such as: faker.address().streetName() As such, it doesn't matter in which package the address provider is, and I don't consider this a real api change. Happy to hear why this would be a breaking change though. |
|
You’re right, I was originally thinking this was changing faker.show() to become faker.entertainment(). |
|
@kingthorin Ah, good point! But no, this won't change in this case. If it did, we probably wouldn't go this route, but we would at least first deprecate the |
No description provided.