[no-Jira] Make enum mocking deterministic

[canac]

Description

<GqlMockedProvider> was picking a random value for enums that could vary between tests. That was a source of flaky tests. This PR switches to using our new CruGlobal fork, which contains the stable random enum fix in CruGlobal/graphql-ergonomock#1.

Checklist:

• I have given my PR a title with the format "MPDX-(JIRA#) (summary sentence max 80 chars)"
• I have applied the appropriate labels. (Add the label "On Staging" to get the branch automatically merged into staging.)
• I have requested a review from another person on the project

[github-actions]

Bundle sizes [mpdx-react]

Compared against 121cd06

No significant changes found

[dr-bizz]

I see that you've altered the yarn.lock file and files inside .yarn. Was there no way to alter the package.json file to do these changes?

[canac]

graphql-ergonomock is an unmaintained project (no commits in 3 years and no recent responses on bug reports), or I'd submit an upstream PR. That's why I'm making the fix to that package as a yarn patch. I can vendor the package and copy all the files into our project so that we can make changes freely if you'd prefer. I think that publishing a fork to npm is probably more effort than it's worth.

[canac]

@dr-bizz Do you have any more thoughts on this?

@wrandall22 Maybe you have input too? For perspective, there are two patches we've made to graphql-ergonomock. One to support graphql v15, and this one to fix a bug with deterministic mocking. I feel like that's acceptable for a patch and if we have to change anything else in the future, maybe we consider vendoring the package.

[wrandall22]

That is probably fine. I agree that if we keep making changes we should fork the repo.

[dr-bizz]

@canac
I recommend that we fork the repo and make the changes there. This is how I've done it in the past, and it better prepares future developers to make changes if needed.

Also, what if the original package is updated in the future? If you use a fork, you can merge those updates into your forked version. This helps keep your version in sync with any upstream improvements.

[canac]

I recommend that we fork the repo and make the changes there.

@dr-bizz One challenge in this case is that our application doesn't consume the raw source code from the graphql-ergonomock package, we consume the published build files. So it's not as simple as forking the repo and making the package a git dependency in package.json. Correct me if I'm mistaken, but we'll have to publish our fork to npm so that we can publish the built files directly. Unless you know of away to get NextJS to run the TS/TSX transforms on package code. Setting up an npm deployment pipeline seems like more effort than it's worth. We could however push the built dist/ files to our fork and then it could be a simple git dependency, if you like that idea.

This complexity is why I suggested vendoring the code since it is a small package (11 files including test files). That will let us run our JSX and TypeScript transforms on the package code. We won't get future updates without manually pulling them in. But the package shows all signs of being abandoned, so I'm not convinced it's worth doing extra work now just in case the upstream repo becomes active again.

[dr-bizz]

Yes, you will need to create an NPM package for this forked repo. This is how I've done it in the past. onesky-utils is a good example. I created Cru's own version of the code when the package wasn't updated and I needed to add a fix. They have since updated their app, so I could migrate God Tools back onto their version and close this one.

[dr-bizz]

I have invited you to CruGlobal NPM organisation

[canac]

I figured out that we can use this syntax to use our fork without having to update all of our imports.

[dr-bizz]

I didn't know this was a feature. This is a great way to add it!

[dr-bizz]

Great work! Thank you for showing me "npm:{package}@{version}"

[dr-bizz]

I didn't know this was a feature. This is a great way to add it!