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

Shared package deep dependencies build wrong file:PATHs. #13

Closed JoachimKoenigslieb closed 1 year ago

JoachimKoenigslieb commented 1 year ago

Hi!

I'm experiencing an issue.

I have a dependency graph that looks like this:

functions <- utils package. utils package <- other_shared_package.

Running isolate succesfully puts both packages side by side in a folder structure like:

./isolate --./dist --./packages ----./utils ----./other_shared_package

Inspecting the package.json of these packages in the isolate folder I see that the utils package has this dep (isolate/packages/utils/package.json):

"dependencies": {
    "other_shared_package": "file:packages/other_shared_package",
}

This causes an error when running yarn install:
"Package "other_shared_package" refers to a non-existing file '"[long_monorepo_path]/isolate/packages/utils/packages/other_shared_package"'."

So it looks like yarn thinks that the file should be relative to the utils folder. Suspecting this, I tried to modify the dependency to be

"dependencies": {
    "other_shared_package": "file:../other_shared_package",
}

Which resulted in a succesful install!

So it seems like the isolate process is not compatible with yarn (I'm running yarn v.1.22.17)?

I'm also experiencing the same issue when trying to deploy to the firestore function service (they try to install using yarn v1.22.19), but debugging there takes a lot longer than debugging locally.

Thanks again for the package. I'm going to see if I can maybe force firestore to install with npm and hopefully that can serve as a temp fix!

JoachimKoenigslieb commented 1 year ago

I've pushed a fix here which seems to fix my issue.

https://github.com/JoachimKoenigslieb/isolate-package.

I'm going to open a PR and we can discuss if anythings needs changes.

0x80 commented 1 year ago

Thanks for reporting and trying to find a workaround.

In my project I also use shared packages depending on other shared packages, but I'm using pnpm so you might be right that yarn wants the paths to be different.

What firebase uses to install your packages I think depends on what lockfile is detected in the folder. But for pnpm the lockfile is not supported yet as part of the isolate deploy, so probably it will then default to npm.