Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
BenJackGill opened this issue Sep 13, 2024 · 3 comments

Comments

@BenJackGill
Copy link

BenJackGill commented Sep 13, 2024

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
Copy link
Owner

0x80 commented Sep 16, 2024

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
Copy link
Author

BenJackGill commented Sep 16, 2024

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
Copy link
Owner

0x80 commented Sep 17, 2024

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 ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants