Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Dropping v1 backwards compatibility? #2213

Open
VIKTORVAV99 opened this issue Jul 14, 2024 · 5 comments
Open

Dropping v1 backwards compatibility? #2213

VIKTORVAV99 opened this issue Jul 14, 2024 · 5 comments
Labels
breaking change

Comments

@VIKTORVAV99
Copy link
Contributor

VIKTORVAV99 commented Jul 14, 2024 •
edited
Loading

🚀 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:

  getResourceBundle(lng, ns) {
    if (!ns) ns = this.options.defaultNS;

    // COMPATIBILITY: remove extend in v2.1.0
    if (this.options.compatibilityAPI === 'v1') return { ...{}, ...this.getResource(lng, ns) };

    return this.getResource(lng, ns);
  }

Where if we dropped v1 compatibility this would become:

  getResourceBundle(lng, ns) {
    if (!ns) ns = this.options.defaultNS;
    return this.getResource(lng, ns);

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.
@adrai
Copy link
Member

adrai commented Jul 14, 2024

needs to be discussed with @jamuhl

@VIKTORVAV99
Copy link
Contributor Author

This search string should give you an indication of who many and which projects are using it: https://github.com/search?q=("compatibilityJSON: 'v1'" OR "compatibilityJSON: \"v1\"" OR "compatibilityAPI: 'v1'" OR "compatibilityAPI: \"v1\"") NOT is:fork&type=code

@jamuhl
Copy link
Member

jamuhl commented Jul 14, 2024

@VIKTORVAV99 nothing against removing some of the compatiblity stuff in future...but https://github.com/search?q=repo:i18next/i18next compatibilityAPI&type=code does not look like some significant size reduction by just removing the compatibility to V1

@VIKTORVAV99
Copy link
Contributor Author

VIKTORVAV99 commented Jul 14, 2024 •
edited
Loading

@VIKTORVAV99 nothing against removing some of the compatiblity stuff in future...but https://github.com/search?q=repo:i18next/i18next compatibilityAPI&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.

@adrai
Copy link
Member

adrai commented Jul 14, 2024

This would be more of a maintenance task than performance task IMO.

this is not hurting us a lot at the moment...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
breaking change
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jamuhl @adrai @VIKTORVAV99