How to use with Turborepo style internal packages where "main" and "types" point to "src/index.ts"?

[BenJackGill]

Have you managed to get this working when packages are not compiled themselves, but instead have main and types pointing directly to src/index.ts?

This style is championed by Turbo Repo on their blog and in the docs for internal packages. The point being we don't need to separately build the package each time. We import it as pure TypeScript and then the app does the transpiling when needed.

I prefer it because I can skip the build step for internal packages, changes appear instantly throughout the monorepo, and it allows for the customization of the tsconfig.json file for each individual app, as opposed to having to having a more generic tsconfig.json version for the packages that aims to cater to all the apps.

But when working with isolate package I cannot get it working because I think it requires that packages are built before they are isolated. Instead I need the internal packages added, and then build everything.

Is that possible?

[0x80]

I tried that, and it sounds nice, but I think it falls apart once you start using path aliases.

I love my aliases too much to give them up. I expect one day the tooling will allow us to write TS without having to jump through hoops building every package, but I don't think we're there yet. I would expect more sources advocating it, if it was a viable solution.

So personally, I'm not interested in going down what path if I can't use path aliases, and I'm not sure if isolate-package would need to change to accommodate it. I suspect the solution lies outside of its context.

I think it will still gather the shared packages code and point dependencies to each other if you set the "files" field in each manifest to be the src folder instead of the build output. Because the "files" is what's being picked up by the pack executable.

So you could give it a try...

[BenJackGill]

Do you mean paths in the packages or paths in the app?

Because my packages do not have any paths. They don't even have a tsconfig.json file. I am relying on the consuming app to process the TypeScript as per it's own tsconfig.json file. But unfortunately isolate-package doesn't seem to work with that setup. Maybe there is something else going on though. I'll try debug it later :)

[0x80]

I'm talking about path aliases like I have ~ pointing go src for each package. If your app imports code from packages that have ~/ in the imports path, and the app itself is also using ~/ to map to its own src folder, than it won't find things.

[BenJackGill]

Yes but none of my packages have paths, and it still doesn't work. So having path aliases set in the package was not the problem as you suggested. Those paths are set in the tsconfig.json file and my packages don't even have a tsconfig.json file because I am importing it directly into the app without any transpiling.

[piedrahitapablo]

The way to do it is building using the tsup-node command from tsup and the noExternal config. Here's the config I used:

// tsup.config.ts
import { defineConfig } from 'tsup';

export default defineConfig({
  entry: ['src/index.ts'],
  sourcemap: true,
  clean: true,
  target: 'node18',
  noExternal: [
    '@my-org/pkg1',
    '@my-org/pkg2',
  ],
});

Regarding the aliases inside packages, unfortunately you will need to define an unique alias for each package, so for example in the tsconfig.json of the internal package:

{
  "compilerOptions": {
    ...
    "paths": {
      "@/pkg1/*": "./src/*"
    }
  }
}

and in the tsconfig.json of the app:

{
  "compilerOptions": {
    ...
    "paths": {
      "@/pkg1/*": "../../packages/pkg1/src/*"
    }
  }
}

I think it's a small price to pay to remove the need for local builds in development.

[0x80]

@piedrahitapablo Interesting. Good to hear that it can work! Having unique path aliases for each package is indeed a small price to pay.

I do think it can lead to code duplication because if I understand it correctly it is inlining the code from shared dependencies inside each package. So if you have package A depending on B and C, And you also have package B depending on C, then code for A will be the result of A+BC*+C

But this might still be very acceptable.

[0x80]

Yes but none of my packages have paths, and it still doesn't work. So having path aliases set in the package was not the problem as you suggested.

@BenJackGill Ah that's a bit of a misunderstanding I think. I never wanted to suggest that path aliases are the cause of your problem. I wanted to point out that the no-build approach might not be viable if you are not willing to give up on using path aliases, and that's why I never tried to make it work.

To get back to your question about isolate. I think you need to make sure "files" are pointing to your src directory. Then you should see the source files being packaged and copied into the isolate directory. Then if your types and main entries point to the source directory as well, I think it could work maybe...

But what @piedrahitapablo explained about setting specific aliases in each package, I suspect that will still break things, because the isolated packages will not have a tsconfig file and even if we make it so that the tsconfig files are included in the isolated output, the alias paths configurations for each would need to be altered I think.

--- edit --- Actually, you have full control over which files are included in the isolated output. Because you can specify a list of files and globs in the "files" field of the manifest. So you could just that to include the tsconfig file probably. But I don't expect it to work without altering the paths in the configs.

[0x80]

@BenJackGill Did you manage to make it work?

I will now explore the no-build approach myself, as I realized that I don't need path aliases for my shared packages. Only for the apps and services that get deployed, because shared packages typically do not have deeply nested file structures anyway.

[BenJackGill]

Sorry I did not get it working. So I switched over to a Vite bundling solution as described here.

It's fast, works without the need for building internal packages, and can use with the emulator.

I'm not exactly sure how it handles lock files though, that's my next thing to investigate.

[0x80]

@BenJackGill Happy to report that I have it working without issues! My monorepo example uses both the traditional and internal packages approach. Check it out https://github.com/0x80/mono-ts

It also demonstrates the firebase-tools fork I've made to preserve live code updates when running the emulators