Yarn v3: The lockfile would have been modified by this install, which is explicitly forbidden. about isolate-package HOT 4 CLOSED

I'm not sure why you'd want to have these manual copy steps. I think the isolate command should handle everything if you configure it as part of the firebase.json "predeploy" configuration.

That being said there seems to be an issue with the yarn lockfile still, preventing it to be use in the deployment as-is, so I advise you to exclude the lockfile using the configuration settings.

For more info see:

#12

https://github.com/0x80/isolate-package/#lockfiles

from isolate-package.

I'm hoping to find some time soon to really get deeper into the lockfile formats for PNPM and Yarn and see if it's possible to modify them to make the deployments work, but it might be difficult to achieve and I struggle to find time at the moment...

None of the manual workarounds solve this issue, and it's not a deal breaker for me, but I guess it depends on your situation and the kind of dependencies you deploy.

A temporary solution could maybe be to use exact versions in your package.json file. It doesn't lock the dependencies of your dependencies, like a lockfile would, but at least the direct dependencies of your project will be the same...

from isolate-package.

I did end up having to not include the lockfile for Firebase Functions deploy. Haven't run into problems with it for now but we plan to migrate away from Firebase Functions anyway.

The reason I was doing the manual copies was because some of the cache and config file live outside of the targetPackagePath. In our Yarn monorepo, the individual workspace /functions has its Yarn artifacts hoisted up to /. I don't think isolate is accounting for that as far as I know. Both .yarn/releases and .yarnrc.yml` are required to configure Yarn to run correctly.

I believe the issue with the lockfile is that the hash for a local file: reference was not a stable identity after the upload to Firebase Functions and Cloud Build. I'm not sure how Yarn is generating that hash.

from isolate-package.

@darkmirage I'm happy to report that lockfile output for classic and modern version of Yarn is now supported in the latest version. At least I've tested it with v1 and v4.

For v4 it does not generate a yarn.lock file, but instead for modern yarn versions it falls back to using NPM. The generated packge-lock in the output is based on the installed node_modules and therefore should match all the versions of your original yarn lockfile. For more info see lockfiles

What package manager is used in the deployment probably shouldn't matter (as long as the locked versions match) so I think this is a viable solution.

I am also working on a typescript monorepo boilerplate which has a branch called use-yarn-modern that you can check out if you want to see a working example with isolate-package integrated.

from isolate-package.