Modular test behaviour on non-modular packages

[cristiano-belloni]

What do you think it should happen if the user runs tests for a non-modular workspace?

For example, suppose that we have a non-modular workspace called nm-pkg in a modular repository and, respectively:

1. We explicitly run tests on that workspace with --package. For example, we execute: yarn modular test --package "nm-pkg" --package "my-other-modular-pkg"
2. We run ghost testing with yarn modular test --changed and nm-pkg's code has changed
3. We run ghost testing with yarn modular test --changed --ancestors and nm-pkg is an ancestor dependency of a workspace that has changed

[benpryke]

My gut is that we should run a test script if it exists, otherwise ignore. This would be the most extensible/customisable option with an intuitive interface.

[cristiano-belloni]

My gut is that we should run a test script if it exists, otherwise ignore. This would be the most extensible/customisable option with an intuitive interface.

I agree to this, but I think we should also warn on stderr if a test script does not exist.

[sgb-io]

Agree with both comments.

We could throw in the case a test script does not exist, but then we'd need some sort of flag/option to tell it to not throw, in the event someone doesn't want their test command to get blocked by these cases.

So, simply ignoring and warning makes the most sense to me

[cristiano-belloni]

POC of running yarn test for extraneous workspaces here: #2167