Split out test dependencies

[bradenmacdonald]

As we discussed and put into OEP-67:

To keep installation and deployment of our MFEs as fast as possible, the “dependencies” field in package.json should reference only the packages needed to build the bundle of the MFE (this includes webpack via frontend-build, as well as any dependencies used in the actual MFE/React code). Any dependencies used only for testing, linting, formatting, or other development tasks should be put into “devDependencies” (e.g. Jest, eslint, TypeScript, @types/ packages, etc.).

However, this repo currently has almost all its dependencies, including the huge jest test runner ecosystem, in dependencies.

If this is just an oversight, things like jest, estlint, react-refresh, webpack-bundle-analyzer, etc. should be moved into devDependencies.

If this is because we want that tooling installed for use by consuming MFEs, I think those should be moved into a separate frontend-testing package, or even better, a frontend-testing sub-package within this same repository.

[arbrandes]

If this is because we want that tooling installed for use by consuming MFEs

This ☝🏼. It's part of the push for standardization of tools across apps. We want to get away from each repo doing its own thing as much as possible (or reasonable).

those should be moved into a separate frontend-testing package, or even better, a frontend-testing sub-package within this same repository.

I'm not opposed in principle, but it must be said that the reason we haven't been too concerned with the point in OEP-67 as it applies to frontend-base is that frontend-base and its build/dev/testing dependencies are only installed once (per site, but there should only be one site per instance). The big problem - if I remember correctly - was having to install the whole shebang over-and-over for 12, 13 MFEs during the tutor-mfe image build.

Again, though, separating it out would probably be a good thing. Having to install jest zero times per build is better than once.

[bradenmacdonald]

This ☝🏼. It's part of the push for standardization of tools across apps. We want to get away from each repo doing its own thing as much as possible (or reasonable).

I'm a huge fan of that, but I see that existing frontend-base MFEs like instructor-dashboard, aspects, and notifications all specify their own Jest/RTL/turbo tooling versions/dependencies, and frontend-template-site doesn't support npm test at all.

I'm not opposed in principle, but it must be said that the reason we haven't been too concerned with the point in OEP-67 as it applies to frontend-base is that frontend-base and its build/dev/testing dependencies are only installed once (per site, but there should only be one site per instance). The big problem - if I remember correctly - was having to install the whole shebang over-and-over for 12, 13 MFEs during the tutor-mfe image build.

Yeah, that's a totally valid point. I was thinking about CI times, not just tutor installs, but it seems like we don't generally split CI jobs up into separate lint + test + build steps, so there's nothing to be gained from streamlining the CI "build" step. I think the low-hanging fruit here is replacing Jest with Vitest, more so than splitting up dependencies.

I do wish we could add comments to the package.json to document all of this.

[arbrandes]

frontend-base MFEs like instructor-dashboard, aspects, and notifications all specify their own Jest/RTL/turbo tooling versions/dependencies

Touché: that kinda shoots down my defense. 😅 But not the intention. Which is to say, I agree we should do something about it.

I think the low-hanging fruit here is replacing Jest with Vitest

There's an epic for that. (As well as replacing Webpack, and eslint.)

more so than splitting up dependencies

Too late, I'm kinda sold on the split, now. 😉 If for no other reason than to standardize on these dependencies and to try and avoid having to declare them everywhere. I'm not sure this is going to work, but it's at least worth investigating.

I do wish we could add comments to the package.json to document all of this.

Right?