0x80 / isolate-package

Isolate a monorepo package with its internal dependencies to form a self-contained directory with a pruned lockfile
MIT License
121 stars 13 forks source link

Support for default folder structure generated by `firebase init` #6

Closed vajahath closed 1 year ago

vajahath commented 1 year ago

First off, thank you for this cool tool. :star: I thought I could give some feedback here. (Also I thought like this should be a part of turborepo!)

Support for default firebase init generated folder structure.

The firebase init command generates a folder structure similar to:

firebase
├── functions/
└── firebase.json

The functions source will go into functions dir.

The most simplest approach I found for adopting this into a monorepo (I'm using pnpm+turbo) is copy this firebase directory into mono/apps.

mono
├── apps
│      ├── web
│      ├── firebase  <-----------------(the firebase directory copied)
│      └── my-another-app
├── packages/
└── pnpm-workspace.yml

And my pnpm-workspace.yml looked like:

packages:
  - "packages/*"
  - "apps/*"
  - "apps/firebase/functions"
  - "!**/test/**"

Unfortunately this setup seem to be not compatible with isolate. As in the docs of isolate, nested packages are not supported. But the firebase directory is not a package (it doesn't have a package.json, but firebase/functions is). I don't know if we call this a nested package, but isolate couldn't out-of-the-box support firebase init folder structure in a monorepo.

So tried to flat it out, copied the content for mono/firebase/functions into mono/firebase including the package.json. And it worked and I did a real deployment :zap: .

But. I had to fiddle around the .env management & firebase emulator setup. Previously during development, firebase functions emulator reloads the changed functions automatically after the tsc build. Now I lost that, even after adding the isolate after the tsc. So now every time I have to stop the emulator, build and tsc ,start again to reflect the changes locally. This was a little painful.

So it would be really cool, if isolate support the native firebase folder structure so that devs feel home at the firebase directory.

0x80 commented 1 year ago

The Firebase team did not have monorepos in mind when they decided on that structure, and I think it is not a pattern I want to encourage.

I would rather spend some time to figure out what is up with the reloading of the emulator, and add a how-to section to the readme. If the emulator relies on this structure for reloading then I would consider that a bug for Firebase to solve.

I don't think the init folder structure is desirable today in the context of a monorepo, so I am reluctant to invest time in this myself.

However, I would accept a PR from someone, as long as it doesn't complicate the code too much.

0x80 commented 1 year ago

I had a look at the firebase init output, and my conclusion is that it is just not designed with monorepos in mind, like I already suspected. It does contain multiple package files, but doesn't utilize workspaces at all.

Nested packages in monorepos is just not a thing AFAIK. I know for certain that Turborepo and Yarn do not support it.

If the Firebase team wants to make it easy for developer to start working with a monorepo setup, they should update their init command to facilitate it. I have no desire to change isolate to support their current structure, so I'm closing this issue.

It should be easy enough to move some files around. It's a bit of extra work, but I think it's worth learning how monorepos are structured anyway.