Open VIKTORVAV99 opened 4 months ago
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
@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 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.