The committers listed above are authorized under a signed CLA.

• ✅ login: vlsi / name: Vladimir Sitnikov (c962c28)

Thanks for the PR.

With Migrate, we're more concerned about backwards compatibility than performance. This is why implementation of various methods is based on how they were implemented in jQuery before deprecation/removal.

The implementation here shouldn't be changed before the upstream version in jQuery is updated; you can find it athttps://github.com/jquery/jquery/blob/3.x-stable/src/deprecated.js. One advantage of making a change in jQuery first is that it has a more comprehensive test suite so any mistakes in the implementation would be detected better.

That said, since the util is deprecated, we'd rather not increase the library size to address an edge case that people shouldn't rely on anyway as we recommend migrating to nativetrim. Please take that into account.

Since any action should first be taken in jQuery upstream, I'm going to close the PR. If a change to jQuery gets accepted, we can then backport the change here.

(note: when submitting a PR, please address any checks errors GitHub throws at you; for example, this PR had a lot of code style errors)

@mgol , the exact.trim method has beenremoved from the base jQuery, so I believe there's no way the contribution could be accepted to jQuery:jquery/jquery@0b676ae

That said, since the util is deprecated, we'd rather not increase the library size to address an edge case that people shouldn't rely on anyway as we recommend migrating to native trim. Please take that into account.

My edge case is that my JIRA instance takes20 seconds to display an issue (it spends most of that time withinjquery.trim).

The implementation is really straightforward, and it doesn't make jquery-migrate significantly bigger.

note: when submitting a PR, please address any checks errors GitHub throws at you; for example, this PR had a lot of code style errors

I am OK to fix the issues if you merge the PR, however,

1. The PR has been "in review" for 2 months
2. You seem to want to close the PR even though it impacts the end-users. Do you really suggest that I should spend MY time on fixing the CI issues with the only outcome of you closing the PR as "won't merge"?

It was removed from themain branch of jQuery; this is the branch where we're merging changes that will land in jQuery 4.0.0 when it's ready. The latest stable line is3.x and it's developed on the3.x-stable branch; the PR would have to be submitted against this branch.

I am OK to fix the issues if you merge the PR, however,

1. The PR has been "in review" for 2 months

This project is volunteer-driven, I don't have active support contract with anyone. And it so happened that I was on vacation recently and before the vacation I was busy at work with hardly any time for open source work.

I'm reviewing PRs when I have time. Usually it doesn't take two months but from time to time I have less time for OSS; you can't expect me to always reply within a given time frame.

2. You seem to want to close the PR even though it impacts the end-users. Do you really suggest that I should spend MY time on fixing the CI issues with the only outcome of you closing the PR as "won't merge"?

I explained why changes need to land in jQuery upstream first, at least as long as the code is still maintained there which is the case here. My time is limited. I'd be happy to review your PR to jQuery.

When you submit a PR to an OSS project, you can't always expect it will get merged; sometimes it doesn't align with the project priorities. In case of jQuery, if you want to avoid spending time on CI issues only to see your PR rejected, it's a good idea to open an issue first, present a concrete use case (like the JIRA example you mentioned here - without a concrete case like that, we can't know if the issue is worth fixing) and wait for the team to approve the approach; then your PR may still get requests for changes but will generally be merged when those are addressed.

For the record, I think this would be a good change to land, although we'd like to compress the code a bit. It's also likely that we'd prefer to use the regex approach in all browsers to make the code smaller; that should still resolve your performance concerns as much as I understand.

@vlsi Sincejquery/jquery#5068 landed, I'm going to reopen this PR. We can merge it if you update the implementation here to match the one that landed in the jQuery PR.