not related to Node.js Middleware support, but this fixes serving static files if non-default distDir is used (test setup for Node.js middleware variants is hitting those conditions)

No change needed - I continue to be a little worried about this way of getting types, but I still have no better solution to offer.

Yeah, I don't have really answer for it other than possibly adoption of Adapters API once it become stable could stabilize types situation as this will be public API with proper semver considerations (tho even with Adapters API if we will look to support multiple Next.js major versions with same adapter, we likely would run in similar problem again)

Under what conditions does registerCJSModules run multiple times?

We don't call it in practice today more than once, so this is just defensive check that made sense to me to not to try monkey-patch Module functions multiple times in case something changed in the future

Unrelated to this line, just made me wonder - What is the leading prefix when a path is absolute?

I think on posix it would always start with / (main use case for us will be posix when edge function is deployed), but on Windows it can be drive letter (we do run integration tests on windows which would do that and also ntl serve on Windows would also use that, which is why I did spend some time on making sure it works on Windows).

ESM allows also to use file:// protocol, but that doesn't seem allowed with CJS's require

I do want to mention that if target is not relative, the possibilities are

• node.js builtins (node:fs, fs etc)
• node_modules package path (package-name, package-name/not-main-export)
• absolute path

Perhaps we could move this into def: EdgeOrNodeMiddlewareDefinition i.e. def.cache or similar

See https://github.com/opennextjs/opennextjs-netlify/pull/3018/files#r2310524071 first

We also should never ever hit condition where name does not end with middleware, so conditional part can be removed and instead cache property will always be undefined. If we ever hit the condition that would set manual cache for actual middleware - this would be a bug to fix anyway

I just did not want to make more changes than necessary here to make review hopefully less involved and maybe do follow up to clean up after, but I guess the fact that I did change for functionName, but not the cache probably resulted in the opposite effect of it being more confusing)

I get it now! Doing the rest in a follow-up makes sense to me.

Was the condition for Next.js Edge Handler: ${page} not ever used?

No, we only support middleware with edge functions. Edge Runtime Pages and API routes are being handled in lambda (and we don't do anything special to do so, it's just how standalone mode operate normally).

I'm not sure why we even had this condition here. I did remove it here because the page does not exist in node middleware's function config and it was just making something we don't even hit messy with conditions.

Thoughts on keeping the two types separate for now and using something like EdgeMiddlewareDefinition | NodeMiddlewareDefinition downstream?

typescript was really unhappy with my attempts to do so for the parts that are shared, so that's why I opted to creating common type with hoisted (duplicated heh) common fields that common handling needs.