use named parameters for node visit context info

[yaacovCR]

Motivation:

1. Some visit context information is rarely used, this could be pathway toward refactoring, future-proofing any breaking changes to come. (see: Refactor visit function #3225)
2. Eventually, BREAK and/or other visit controllers could be added as third argument directly to the visitor method rarely than exported from the library. (see Separate interfaces from implementations for exported classes #3616)

[netlify]

✅ Deploy Preview for compassionate-pike-271cb3 ready!

Name	Link
🔨 Latest commit	d1e3180
🔍 Latest deploy log	https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/62990e7848527600095adb7f
😎 Deploy Preview	https://deploy-preview-3619--compassionate-pike-271cb3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[yaacovCR]

Motivation added above.

[IvanGoncharov]

@yaacovCR I'm totally for this change 👍
But it makes a breaking change without migration path and means you can't support v16 and v17 in the same code base.
Are we sure we want to do this?

[yaacovCR]

Thanks for taking a look. We could try to rework as new format that is optional in v17 but required in v18.

[yaacovCR]

Alternatively we could backport the backwards compatible version to v16 and just deprecate in v17

[yaacovCR]

Backwards compatible version is easier said than done. We can't just change the second argument to keyOrContext, because the directionality is actually opposite, our users are supplying the function, rather than us writing it. How would we know which type of function we were supplied and whether to pass the key or the context?

What seems possible, but not necessarily the best choice: we could make our users specify in some way which type of visitor function they are passing, and then require them to pass it that way. Easiest but ugliest, we could create an entire new function called visitWithNamedVisitorFnArguments that supercedes visit and then deprecate visit.

Adding to next js-wg. If you are reading this, please feel free to chime in.

[IvanGoncharov]

@yaacovCR As a suggestion to allow a faster review cycle, can we have a rule where PRs either blocked on the technical solution or WG discussion is marked as draft?
https://github.blog/changelog/2020-04-08-convert-pull-request-to-draft/

This will make the "Pull requests" tab more representative.