Skip to content

Allow multiple utils modules on Shared Settings #315

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

Closed
6 tasks
Belco90 opened this issue Apr 5, 2021 · 4 comments
Closed
6 tasks

Allow multiple utils modules on Shared Settings #315

Belco90 opened this issue Apr 5, 2021 · 4 comments
Assignees
Labels
question Further information is requested
Milestone

Comments

@Belco90
Copy link
Member

Belco90 commented Apr 5, 2021

It would be interesting to allow "testing-library/utils-module" to support multiple modules. For doing so:

  • "testing-library/utils-module" should expect an array of strings
  • all tests cases setting "testing-library/utils-module" must be updated
  • add new test cases in fake rule to test several "testing-library/utils-module" set
  • update isAggressiveModuleReportingEnabled to check array length is greater than 0
  • update detectionInstructions to check if some of the utils modules end with corresponding string.
  • update migrating guide to reflect this change

This example makes it seem like this can only be a single string and not an array? Not sure if it'd add too much complexity to support multiple utils modules.

For example a user could have many custom selectors each imported from a different module. Probably not common, but just calling it out.

Originally posted by @CreativeTechGuy in #312 (comment)

@Belco90
Copy link
Member Author

Belco90 commented Apr 5, 2021

@CreativeTechGuy ok so I've been trying to implement the first approach for this but it's not so easy as I thought. Apart from changes mentioned in the description, all checks around custom test utils should be updated to look for specifiers on an array rather than a single string.

The plugin is not ready for this, since it assumes it will have a single import, not several of them. This implies a lot of work, including corresponding tests to make sure different cases with several imports work as expected.

For this reason, I think it's better to leave this as a future improvement for a 4.X release.

What I can do now is rename the setting to something like custom-utils so it's generic enough for receiving a single string or an array in the future.

@Belco90 Belco90 added enhancement New feature or request question Further information is requested and removed enhancement New feature or request labels Apr 5, 2021
@CreativeTechGuy
Copy link

Wow thank you for spending so much time on this suggestion. But I definitely agree, we should wait and see if there's any demand for it since it's a non-trivial change.

@Belco90
Copy link
Member Author

Belco90 commented Apr 6, 2021

No problem. I thought it would be a quick win, but it's not. I'm gonna close the ticket but reference it in v4 issue as a future improvement.

@Belco90 Belco90 closed this as completed Apr 6, 2021
@MichaelDeBoey MichaelDeBoey added this to the v4 milestone Apr 15, 2021
@rosczja
Copy link

rosczja commented Apr 20, 2021

I would definitely like to have this feature, but I understand that this is not trival to implement.

We have two different types of tests: unit and integration. Both use a different custom render function and re-export testing-library stuff. Each type has its own module.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants