Faker 1.9.4 has so many more dependencies than Faker 1.9.3.

[myronmarston]

Between Faker 1.9.3 and Faker 1.9.4, faker evolved from a small, light-weight library that I can add to new projects without thinking about it much to being a very, very large dependency that installs a ton of other gems.

When a project depends on faker 1.9.3, here's the set of gems that gets installed with the project:

concurrency-ruby
faker
i18n

Faker itself plus 2 dependencies. A small number of dependencies. Easy to vet.

Installing Faker 1.9.4 now installs the following:

concurrent-ruby
equatable
faker
i18n
pastel
strings
strings-ansi
thor
tty-color
tty-pager
tty-screen
tty-tree
tty-which
unicode-display_width
unicode_utils

That's faker plus 14 dependencies. I don't have the time or desire to vet these gems and make sure I'm comfortable adding them as dependencies to my project. As far as I can see, these all trace back to the new CLI feature in #1507, which seems like a nifty feature but not like something that is core to faker.

Is it important that the CLI lives in faker itself? Could it exist as an external gem that users who want the CLI (and are happy installing lots of dependencies as part of it) can opt-in to? Alternately, could a faker-core (with just the core faker logic, no CLI, and a small number of dependencies) be extracted so users (like myself) who don't plan to use the CLI don't have to take on so many dependencies in our projects?

On a side note, I was very surprised to see this all change during a patch release. It seems very strange to add new major features (and a ton of new dependencies) during a patch release. It definitely wasn't something I was expecting when I bumper faker to 1.9.4! Is there a defined semantic for faker for what constitutes a major vs minor vs patch version bump? The semver.org semantics have been adopted by many projects (and faker doesn't have to follow suit) but it'd be nice to know what the versioning semantics are so I can adjust my expectations :).

[stympy]

Thanks for raising this issue, Myron! You make great points (both about dependencies, and the versioning), and I agree with them. :)

I'm not 100% sold on semver, but, in retrospect, adding the weight of the CLI with its dependencies was a bit much for a patch-level release. Sorry about that!

We have tossed around the idea of having a faker-core gem, and I'm still open to that option. I am also open to the idea of splitting the CLI back out into separate gem in order to decrease the dependencies, and I'd be interested to hear any input anybody else might have on that idea.

[Zeragamba]

I think the CLI would be better suited to a separate gem, as I don't think most users will use it. Also one of it's deps had an issue that was causing Faker's test suite to fail unexpectedly.

[myronmarston]

I think the CLI would be better suited to a separate gem, as I don't think most users will use it.

I agree, although it's worth noting that it started as a separate gem so I wasn't sure if extracting it back to a separate gem was an option on the table.

[vbrazo]

@stympy @myronmarston I'm starting to do some research and see how we can split the faker gem. I'll spend some time over the next days.

Here is the organization: https://github.com/faker-ruby.

[vbrazo]

btw your issue has received 6 likes so far. This should be a good indicator.

[akabiru]

Thanks for raising this issue @myronmarston , it is a valid concern. Apologies for the late response on my end (on vacation 🏖 ).

Repost of my thoughts: #1507 (comment)

"I think the move to a separate gem is the sensible approach. And allows users to opt-in into using the gem.

It did start as a separate gem , no strong objections on this one. 🙂

@vbrazo I'm happy to assist with the extraction &/migration as well."

[vbrazo]

@myronmarston #1653