Adding examples of using next-transpile-modules in custom SSR (without NextJS)

[morsmodr]

Is your feature request related to a problem? Please describe. I am exploring a custom SSR solution for a React-Redux-Redux-Observable project. Redux-Observable doesn't support SSR, especially for side-effects which are infinite in nature and as a result NextJS getServerSideProps doesn't work as the epics never shutdown. Example of one and done (finite) epic implementation with shutdown concept here in case you are curious

Describe the solution you'd like As I am doing a Custom SSR solution with the classic renderToString route, I have found that babel doesn't transpile ES6 node_modules packages to ES5 and I get the same Unexpected token 'export' that one gets with NextJS SSR, without this (next-transpile-modules) package. Would it be possible to add an example of using this repo with a custom SSR solution? I don't see any dependencies to NextJS itself in this repo, so this is something that should be possible or I am not understanding something

Describe alternatives you've considered Refactoring the large app to remove RO is not possible as my SSR work is fundamentally a PoC (Proof of Concept) and the refactor effort would be quite large. Switching to Redx-Saga is also a significant effort

[martpie]

I don't see any dependencies to NextJS itself in this repo

NTM is a plugin for Next.js, using the Next API for plugins, and heavily customizing the native webpack configuration of Next.js.

Youre usecase is just the initial scope of NTM, but NTM grew to include a lot of additional features (CSS, TS, basically anything supported by Next.js).

The important bit for your usecase is here: https://github.com/martpie/next-transpile-modules/blob/c5f548e9adafdc9c5afb8a97f15a92f92bdcb266/src/next-transpile-modules.js#L170-L176

matcher is the function run to determine if the plugin should be transpiled or not, ans use is basically babel-loader.

So you're probably just interested in adding something similar (assuming you use Webpack) to your project bundler config, but adapting this for other shouldn't be too hard.

Good luck!

[martpie]

On a sidenote, I would refine your usecase/architecture first probably. Building your own SSR solution may will not be worth the hassle, especially if it's just because you could not use a certain package server-side.

• await import
• try/catch
• Webpack magic comments

are patterns/tools you should be able to use to include Redux-Observable from the server-side. Re-inventing the wheel for SSR is probably the worst you can do at this point, for. the long-term maintainability of your app. But I'm not sure to completely understand your usecase, so I may be wrong.

[morsmodr]

Thanks for the answers and yes I am still not giving up on the NextJS route yet :)