What?

This is an issue for the actual work that needs to be done around #3772.

Problem

Due to the fact we are doing a fork and how golang modules work we need to somehow tell the go toolchain that it now needs to use the goja fork from this place.

Solutions:

fork and use replace

First this means we need to keep it called goja and it means anyone else using this fork will have to forever use replace, unless we break again and move to one of the below methods.

Due to how xk6 works it also means that we will need to teach it to add replace for goja and figure out the correct version. Which also means that in order for people to continue using xk6 they need to know they have to upgrade it.

The only upside of this option is that we don't need to change much code.

At least until we do any visible changes to the API (new functions, types, changing some of them) then every extension also needs to put replace clause in its repo as well.

Given the above while it seems like the "easiest" option it will continue to haunt us forever. So I personally think this is a bad idea.

fork and switch

The obvious thing is to name the new module something and then go over the code and change it to use that new module.

This would break every extension the moment it has to be compiled with this new k6 - and they will need to the exact same thing.

The change is arguably fairly easy and can be done with regex maybe gopatch for some parts.

We can also make PRs for every extension as we have done some times before

Unfortunately due to how experimental modules are implemented the original PR for this within k6 will be quite the nightmare and will need to happen for all extensions. This potentially might block people working on other work and likely will be quite hard to revert if we end up needing to pause the whole thing.

As such if we are going to be doing this I would recommend doing it early in the release.

alias, switch and then fork

The alternative is to make a new module with the new name and instead of putting the goja code in - we alias every type and copy-paste the consts and variables.

This way you can now point k6 code to this new module - it will work. But at the same time every extension will be able to build as for go those are the same types and the functions and variables and consts get matched by values.

This than lets us having a much smaller initial PR for k6, go through all the experimental modules within the next days/weeks, update them to the new module and update them in k6.

We can do the same for extensions, and they will work with both old k6 but also the version of k6 we release with this.

After 1 release of k6 we make new version of the module now with the actual goja code - actually forking it. At this point updating it in k6 will just work and as long as extensions have actually updated - it will also work for them.

AFAIK there is no problem with this idea, and we only need to do it for the goja package itself not for any of the other ones in the module - as only k6 cares about parser and ast

In practice the amount of work here is more or less the same - I already have the code for the alias - took me some regexing and experimenting - probably an hour in total. And have "dry" tested the idea within a go workplace.

The major upside is that we don't need to do all of these changes all at once. This IMO will make the changes considerably easier to actually do without that much cross team coordination.

The downside is it having more steps and potentially adding some confusion in the period of transition.

If we agree to this we can start doing it this release and fork at the beginning of the next one.