How to determine whether transpilation is for the client-side or for the server-side?

[brillout]

Hi, author of Telefunc here; we'd love to write a SWC plugin for it.

The Telefunc transformer's result is different depending on whether the code is being transpiled for the client-side or for the server-side. Is there a way to get that information from within a SWC plugin?

I've been looking at current SWC plugins (swc-project/plugins) but I couldn't find any client/server discrimination so far.

Looking forward to supporting Next.js 13's --turbo development.

[kdy1]

@kwonoj Any ideas?

[kwonoj]

In short, there's no way yet. Server / client is a boundary swc doesn't have it out of the box as swc is agnostic to those, naturally we don't have support.

I'm not sure if there's canonical way to support this. Typical way could be things like filename (xxx.server.ts) to distinguish.

[Aslemammad]

Hello, The developer of SWC Telefunc is here :)

As we've been developing multiple plugins for telefunc in different bundlers, we've seen different ways to distinguish. Here's one for webpack/next.

[kwonoj]

Yes, that's very webpack specific and we currently do not have equivalent _compiler pass down to plugins.

[brillout]

Typical way could be things like filename (xxx.server.ts) to distinguish.

That's actually a good example: a .server.js file needs to be transpiled to something else if the target is the client-side (e.g. a poison pill if .server.js is server-side-only code).

Another example is React Server Components which transforms client-only components to replace them with a special reference object (which it only does if the target is the server-side).

It's also a common practice for Vite plugins to depend transformation on whether the target is client-side or server-side.

I think it's a must-have. I wonder what the plan for SWC is?

I've seen this get_context() thing. I'm not familiar with SWC's code, but it seems to be about passing information down, which SWC plugins can then access.

[kdy1]

Maybe we can accept arbitrary context from the caller and pass them down to the plugin on request.
It would require patching next.js, though

[brillout]

It would require patching next.js, though

If today SWC isn't aware of whether it's being called for the client-side or server-side then I'm thinking Next.js needs to be patched anyways.

Maybe we can accept arbitrary context from the caller and pass them down to the plugin on request.

👍 Although I think it's such important information that I think it would make sense to enforce the SWC caller to provide that information.

[kdy1]

No I don't think it should be forced

[brillout]

👍 I guess it's fine long as SWC plugins have the information. (Although I'd be curious to know why you think that 😁.)

[kdy1]

It's too next-specific. Why should it be forced? It can abort on plugin load and I'm fine with it but as swc is a building block for rust-based web tools, forcing it is way too opinionated.

[brillout]

Ok that makes a lot of sense. Being able to use SWC for other use cases is neat.