Feature Request: Export a helper function that lists all the internal packages

[BenJackGill]

It would be great if you could provide a function that returned all the internal package names as a string array.

This would make integrating isolate-package and tsup much simpler.

At the moment we have to manually list all of the internal packages in the tsup noExternal config property. But sometimes I forget to do that and I see strange errors that are hard to track down until I remember to add any new internal packages to the noExternal list.

I assume isolate-package has a way of identifying the internal packages, so if you could export that as a helper function for us we could easily use it within tsup to solve this issue.

This is how my current tsup.config.ts file looks. I have to manually list all the internal packages. This is error prone because I often forget to list them here.

import { defineConfig } from "tsup";

export default defineConfig({
  clean: true,
  entry: ["src/**/*.ts"],
  format: ["esm"],
  // List all internal packages here
  noExternal: [
    "@repo/firebase-functions-helpers",
    "@repo/firestore-converter",
    "@repo/types",
    "@repo/tsconfig",
    "@repo/utils",
  ],
  sourcemap: true,
  treeshake: true,
  tsconfig: "tsconfig.json",
});

This is how is could it work if you exported a helper function for us. The internal packages are automatically listed using an isolate-package helper function named internalPackages (just a name suggestion).

import { defineConfig } from "tsup";
import { internalPackages } from "isolate-package"; // <--- Possible helper function exported from isolate-package

export default defineConfig({
  clean: true,
  entry: ["src/**/*.ts"],
  format: ["esm"],
  // List all internal packages here
  noExternal: internalPackages(), // <-- Using it here to auto update the noExternal list
  sourcemap: true,
  treeshake: true,
  tsconfig: "tsconfig.json",
});

[0x80]

What happens if you don't list the packages?

I am using tsup and I've never had to list my packages under noExternal. AFAIK it's perfectly fine to treat the packages as external, because the manifest points to the local directories within the isolated output.

I see no reason to bundle them with your js output. It seems you would then deploy the packages code twice.

[BenJackGill]

Without using noExtremal in tsup.config.ts I get errors like this:

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /Users/BenJackGill/Dev/seoturbo/packages/firestore-converter/src/index.ts
    at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:160:9)
    at defaultGetFormat (node:internal/modules/esm/get_format:203:36)
    at defaultLoad (node:internal/modules/esm/load:143:22)
    at async ModuleLoader.load (node:internal/modules/esm/loader:409:7)
    at async ModuleLoader.moduleProvider (node:internal/modules/esm/loader:291:45) {
  code: 'ERR_UNKNOWN_FILE_EXTENSION'

I am using the internal packages strategy without a build step for the packages, so maybe that could be the difference between both of our outcomes.

When I use noExtremal it deploys just fine.

[0x80]

Ah yes that makes sense!

I think it's a good suggestion. It should be easy to add, but I'm not sure when I'll get to it. Feel free to submit a PR ;)

[BenJackGill]

I tried to attempt this feature today but I'm afraid I'm not skilled enough, sorry. Might try again when I have more time.

[0x80]

Hi Ben,

I am tempted to help you out, but I am really swamped with work and personally I have no use for it.

When I first created mono-ts and wrote about it, there were a few things different from now:

• Turborepo didn't have a watch task
• I didn't understand that TS project references were sufficient to get go-to-definition working.
• Using incremental builds for TS seems to have helped my setup too

I've updated / simplified the mono-ts boilerplate to reflect these things. In my projects I no longer perceive the build stage as friction, and things seem to work smoothly overall.

For context, I work on two mid-sized projects, each with about 8-12 packages and 50-100k lines of code.

I suspect that not a lot of people are using the internal packages strategy, and as build tooling improves I think it might become less relevant.