Include a mention to "sideEffects" in the Internal Packages documentation

[anthonyshew]

Discussed in #6363

^{Originally posted by vimtor November 4, 2023}
To provide context, I was transitioning from a single Next.js project to a monorepo. As part of this transition, I created an internal package for my Prisma database and updated the imports from "../lib/prisma" to "@acme/prisma". However, this change resulted in a new error that started appearing on some Next.js pages:

PrismaClient is unable to be run in the browser.

This was unexpected because I hadn't made any other changes. Upon investigation, I realized that the error was caused by importing types into client components and the Prisma client being bundled in the client code:

import { User } from "@prisma/client";

For the record, I should probably import the above using import type, but that's beyond the point. Additionally, I needed to import some enum values as values, not types.

I recalled that for tree-shaking to work, the package should be side-effect free. By adding "sideEffects": false to the internal package's package.json Next.js was able to successfully tree-shake the package.

I'm starting this discussion because I'm not an expert on library bundling, and I'm unsure if what I'm doing is incorrect in any way. However, I thought it would be a valuable addition to the internal package's documentation if it is indeed important.

[anthonyshew]

Doing some cleanup of our Issues list and was reminded of this Issue. This has been mentioned in this section of the docs: https://turbo.build/repo/docs/core-concepts/internal-packages#limitations-and-tradeoffs-1