Server files included in the browser bundle if inside a 3rd party library

[buzinas]

Howdy!

We're creating a CMS based on Remix, and our package (@fasterfront/cms) exports two functions, usePageData (wrapper of useLoaderData) and pageLoader (to be used as the loader of your route).

The general goal is to provide a quick way to get all data needed for a specific route, eg:

import type { V2_MetaFunction } from '@remix-run/server-runtime'
import type { Pages } from '@fasterfront/cms'
import { usePageData } from '@fasterfront/cms'

export { pageLoader as loader } from '@fasterfront/cms'

type Path = '/about'

export const meta: V2_MetaFunction = ({ data }: { data: Pages[Path] }) => [
  { title: data.title },
  { name: 'description', content: data.description },
]

export default function About() {
  const { data } = usePageData<Path>()
  return <div>{data.main.disclaimer}</div>
}

On our package's index.ts file we have something like export { pageLoader } from './pageLoader.server'. We assumed Remix compiler would strip this from the browser bundle, but it didn't.

We tried many different approaches (eg exporting a function and only requiring the file on-the-fly if window is not present), but we couldn't find a way to leave our server-side code out of the consumer's browser bundle.

Then I decided to take a look at Remix compiler code, and I figured out that it uses the emptyModulesPlugin only when the .server.[ts|tsx|js|jsx] is inside the consumer's app folder:

Although it's understandable that we shouldn't assume that all 3rd party libraries follow Remix convention, we should provide a escape hatch, so libraries can "inform" Remix compiler that a specific file should only be used in the server.

Otherwise, our "solution" for now is to have a cms and a cms.server file on the consumer's app root that just re-exports the functions from the library in order to make sure "server" code doesn't appear in the bundle. We'd like to avoid this extra friction.

Any thoughts?

[buzinas]

Small bump on this one @jacob-ebey, @pcattori, @ryanflorence.

[buzinas]

cc @mjackson since I've seen you tweeting a lot about something very similar a few minutes ago.

I'd love to contribute to this btw.

[depsimon]

We have the same requirement when sharing loaders in a monorepo context.

Otherwise, our "solution" for now is to have a cms and a cms.server file on the consumer's app root that just re-exports the functions from the library in order to make sure "server" code doesn't appear in the bundle. We'd like to avoid this extra friction.

Thanks for the solution, that does the job. 👍

[ViktorPontinen]

Stumbled across this "issue" now as well. We run a mono-repo using NX and have multiple libraries generated that we would like to denote as "server only" libraries. For now we've had to resort to Otherwise, our "solution" for now is to have a cms and a cms.server file on the consumer's app root that just re-exports the functions from the library in order to make sure "server" code doesn't appear in the bundle. We'd like to avoid this extra friction. as well.