Stop deprecating and changing everything for each version

[zacharytyhacz]

The deprecation warnings are getting insane. Once I upgrade and refactor usage, i only upgrade to be known it's all deprecated AGAIN.

Using eslint-deprecation rule

[ST-DDT]

Thanks for telling us about the problems you have when using Faker.
Most of the changes in API were required to have an open and extensible base that is easy to use and consistent in it's structure.
We tried to minimize the occasions where a method was changed twice, sadly the module renames and some others weren't able to satisfy this goal. We use the community feedback we get in PRs and other channels such as Discord to improve the API and minimize (later) changes to our API.
The good news is that with v8.x we think that we now have identified the last methods that needs to be updated to our standards.
So there shouldn't be any more deprecation in v9 (at least we plan to not need them then).
We would like to invite you (and the rest of the community) again to check our API for inconsistencies and other problems now, so we can address them in v8.x, so v9+ will be only feature additions instead of changes.

I would like to use this opportunity to ask you (and the community) these questions to better understand you:

• Which modules/methods do you use the most?
• Which modules/methods are causing you the most grief/trouble upgrading?
• Do you have a suggestion on how to proceed with fewer deprecations or other ways of deprecation?
• Do you know of any inconsistencies in our API that needs fixing?
• Is there a feature/function/options missing, that you would like to have?
• Are there any changes that you would like to revert?

Thanks for your feedback.

[mcmxcdev]

@zacharytyhacz Deprecations and code removals are normal when moving from one major version to the next. Code always evolves, and it's not that hard to do a string search and replace for updating the methods. faker is an amazing lib where maintainers pour a lot of time and effort in it, so that should be appreciated properly.

Without thinking too much about it right now, our team would care most about having the whole project be tree-shakable properly, this open issue seems related: #1791

It happens easily to accidentally end up with faker in the prod bundle and then the application size blows up like crazy.

[matthewmayer]

I would also add that Faker is not the kind of library where its vital to upgrade frequently. It doesn't have any dependencies and there are very unlikely to be security issues with using an older version. Most updates are minor improvements to locale data, small bugfixes or improvements to make the API more consistent. So if you have a working Faker x.y.z version unless you need a specific new feature there's no big hurry to upgrade to the latest version or deal with deprecations immediately.

[ST-DDT]

I will be closing this issue since no more discussion or suggestions are ongoing, but we keep it in mind when changing faker's code.