fix(containers): remove @redwoodjs/api-server's @redwoodjs/internal requirement

[jtoar]

In the last stage of optimized Dockerfiles, you usually see something like this...

RUN --mount=type=cache,target=/root/.yarn/berry/cache \
    --mount=type=cache,target=/root/.cache \
    yarn install --inline-builds && yarn add react react-dom @redwoodjs/api-server @redwoodjs/internal prisma

(Source https://gist.github.com/callingmedic911/15e87c3d26cd4c2c22cad780ff832f75#file-dockerfile-L43-L44).

This instruction only installs the runtime dependencies to keep the final image small. But unfortunately, @redwoodjs/internal is currently a runtime dependency because @redwoodjs/api-server imports a few helper functions from it. @Josh-Walker-GM and I realized this when we derived the experimental @redwoodjs/fastify package from @redwoodjs/api-server, and simply copied over the functions.

@redwoodjs/api-server doesn't list @redwoodjs/internal as a dependency, which is a bug and which is why optimized Dockerfiles have to install it alongside @redwoodjs/api-server manually, but we can use this to our advantage. Removing the need to install @redwoodjs/internal would shave at least ~100 MBs off the last stage of an optimized Dockerfile's size, so this is worth the tradeoff of repeated code.

There's one caveat: the watch binary. The watch binary needs the buildApi function from @redwoodjs/internal, which I'm not going to copy over. But this doesn't matter for the final production stage, and doesn't affect any existing apps because @redwoodjs/api-server never listed @redwoodjs/internal as a dependency in the first place.

[Tobbe]

This is fine and I have no objections on getting it merged as-is. But I wanted to ask - did you @jtoar (and previously you and @Josh-Walker-GM) consider extracting the methods out into a separate package instead of duplicating them? I think we use the files functions all over the place, so it's possible a lot of other packages would also benefit, if nothing else, by getting clearer dependencies on what they actually need just by looking at something like the nx graph (instead of seeing just a broad dependency towards rwjs/internal).

[replay-io]

19 replays were recorded for 8861296.

0 Failed

19 Passed

• requireAuth graphql checks
• useAuth hook, auth redirects checks

  locator.waitFor: Target closed
  =========================== logs ===========================
  waiting for locator('text=Username `testuser@bazinga.com` already in use') to be visible
  ============================================================

• Check that a specific blog post is prerendered
• Check that about is prerendered
• Check that homepage is prerendered
• Check that meta-tags are rendering the correct dynamic data
• Check that rehydration works for page not wrapped in Set
• Check that rehydration works for page with Cell in Set
• Check that rehydration works for page with code split chunks
• Check that you can navigate from home page to specific blog post
• Waterfall prerendering (nested cells)
• RBAC: Admin user should be able to delete contacts
• RBAC: Should not be able to delete contact as non-admin user

  locator.waitFor: Target closed
  =========================== logs ===========================
  waiting for locator('text=Username `admin@bazinga.com` already in use') to be visible
  ============================================================

• Smoke test with dev server
• Smoke test with rw serve
• Loads Cell mocks when Cell is nested in another story
• Loads Cell Stories
• Loads MDX Stories
• Mocks current user, and updates UI while dev server is running

View test run on Replay ↗︎

[jtoar]

@Tobbe I don't remember if we did, I feel like we didn't because it's only these two functions and I'm not sure where we would've put them. These functions feel like they belong in #7039 or some similar introspection package, but I don't want that PR to take on a new life just yet unless it's super clear it'll land, and when Josh has a little less on his plate. Definitely share you concern though and wish we had a solution

[Tobbe]

Thanks, that's all I wanted to hear 🙂

[Josh-Walker-GM]

I started a more stripped back introspection package a few weeks ago and had got most of the critical stuff working. The issue was I went and experimented with SWC as the parser to produce the AST. If I remember correctly it was troublesome because it had no built-in traversal and there were some issues with no typescript types. I also hadn't decided if SWC was too large a dependency or not.

Anyway, yeah agreed with everyone on this and I haven't forgotten the need for an updated introspection functionality.

[Tobbe]

Interesting that you looked at SWC
This is from the Vite package in my RSC experimental branch

[jtoar]

I didn't know how mock this function in a file that has a default export, so I just moved it to a different file