[feature] add an option to return value from `logTestingPlaygroundURL` instead of printing to console

[kaminskypavel]

Describe the feature you'd like:

logTestingPlaygroundURL is such a powerful feature 💪!
The only issue with it is always printed to the console if you're using test runners such as (wallaby.js) this is extremely inconvenient.

it'd be great to have a similar getTestingPlaygroundURL method or add Options parameters to the original method.

Suggested implementation:

would you be open for a PR?

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

Test

once this is implemented we will be able to work faster with the value both in VSCode and other IDE's

[MatanBobi]

Hi @kaminskypavel, thanks for the detailed request.
Any chance you can elaborate a little bit more about the need? I understand what you're looking for but just trying to understand if this is something that's worth adding to the core library and whether it can be done on the user-space.

[kaminskypavel]

Hi @kaminskypavel, thanks for the detailed request. Any chance you can elaborate a little bit more about the need? I understand what you're looking for but just trying to understand if this is something that's worth adding to the core library and whether it can be done on the user-space.

Hi @MatanBobi , nice to meet a fellow "Tel-Avivian" here :)
sure let me elaborate..

From my experience, people who are serious about their tests (or following a TDD/BDD methodology) rarely use CLI only,
usually there are several tools involved in the process, such as Wallaby.js (which I'm a huge fan of) , Jest Runner , Vitest Runner and maybe some others too...

the great deal with such tools , is the ability to "watch" and log values directly to the IDE window without switching to the CLI or running a separate process. here's an example

The problem is, logTestingPlaygroundURL() doesn't work since it prints the value directly to the stdout of the running process, so the values are hidden in the log window.

is this something worth adding to the core library?

I really think so.
My suggestion is to expose a getTestingPlaygroundURL or add an optional parameter to logTestingPlaygroundURL so it will return the value (similar to .debug() ), that way can click through directly from the editor window, and.. this will lead the way to build more versatile extensions in which the user copy-pastes the value without navigating to the playground first

either way - it's already there, it's just a matter of exposing it.

I hope, this clears things up.

[MatanBobi]

Hi @kaminskypavel, sorry it took me some time to respond.
I understand what you're saying, I think we can support this one, even if the use cases are minimal.
This one is up for grabs, I'll give it a try if I'll have an hour soon..

[github-actions]

🎉 This issue has been resolved in version 8.16.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[kaminskypavel]

woo hoo! 🚀