-
-
Notifications
You must be signed in to change notification settings - Fork 640
-
-
Notifications
You must be signed in to change notification settings - Fork 640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dropping v1 backwards compatibility? #2213
Comments
needs to be discussed with @jamuhl |
This search string should give you an indication of who many and which projects are using it: https://github.com/search?q=%28%22compatibilityJSON%3A+%27v1%27%22+OR+%22compatibilityJSON%3A+%5C%22v1%5C%22%22+OR+%22compatibilityAPI%3A+%27v1%27%22+OR+%22compatibilityAPI%3A+%5C%22v1%5C%22%22%29+NOT+is%3Afork&type=code |
@VIKTORVAV99 nothing against removing some of the compatiblity stuff in future...but https://github.com/search?q=repo%3Ai18next%2Fi18next%20compatibilityAPI&type=code does not look like some significant size reduction by just removing the compatibility to V1 |
While true that this alone won't reduce the actual code size by a lot it will allow you to remove all V1 tests, at least 3 dev dependencies only used in those tests and make it easier to change some of the other code behavior later on. For example there was a big chunk of if statements that could be refactored into a switch case while maintenance the same functionality in the newer versions but not with V1 as it relied on some non explicit behavior. This would be more of a maintenance task than performance task IMO. |
this is not hurting us a lot at the moment... |
🚀 Feature Proposal
I would like to drop compatibility with the V1 API and JSON formats.
Motivation
There is a lot of code in the package just to handle V1 API and JSON compatibility and the whole package could be made faster and smaller by dropping all these special handling cases.
This would have to be done in the next major version as it's a breaking change.
Example
Here is a simple example:
Where if we dropped v1 compatibility this would become:
This removes a lot of code that will never be run in modern usages of the package, reduce branching and should make the code easier to maintain in the long run.
This is just one example of this and there would be several opportunities to streamline the codebase with this.
The text was updated successfully, but these errors were encountered: