Skip to content

Conversation

@lazka
Copy link

@lazka lazka commented Oct 21, 2025

Rollup Plugin Name: pluginutils

This PR contains:

  • bugfix
  • feature
  • refactor
  • documentation
  • other

Are tests included?

  • yes (bugfixes and features will not be merged without tests)
  • no

Breaking Changes?

  • yes (breaking changes will not be merged unless absolutely necessary)
  • no

If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.

List any relevant issue numbers:

Description

When passing patterns to createFilter() it would normalize and parse the patterns on every call to the returned filter function.

Just do it once at the start instead.

Something I've noticed while working on #1916.

When passing patterns to createFilter() it would normalize and parse
the patterns on every call to the returned filter function.

Just do it once at the start instead.
@lazka lazka requested a review from shellscape as a code owner October 21, 2025 07:32
Copy link
Collaborator

@shellscape shellscape left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. Could you please add a test that performs multiple calls to getMatcher in succession, and add the PR number in the test description? That will help protect against future possible regressions.

@lazka
Copy link
Author

lazka commented Oct 30, 2025

Thanks for the review. Sadly I don't quite understand what type of test you have in mind. Do you want me to move getMatcher to the module level and export it, and then test it? Though it still behaves the same, so there is no way to test the behaviour change.

Adding a spy on picomatch would makes sense, but I couldn't find a way to do that.

@shellscape
Copy link
Collaborator

shellscape commented Nov 3, 2025

No worries. Your PR is changing the code so that instead of creating the matcher on every invocation of test, it's creating it once in the scope above, and every invocation of test uses the same matcher. To prevent against regressions of that change, we need a test in place which asserts that test is using the single matcher. Spitballing here - that could be as simple as exporting getMatcher individually, and using a symbol attached to the pattern to assert that each invocation of the resulting test method is using the same one. (It might be enough to copy and past the above to an agent and see what one comes up with)

Changes like this one are very susceptible to regressing in a project like this. We use tests to prevent that from happening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants