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

On yarn install, and the cache #41

Open
angerman opened this issue Feb 19, 2022 · 2 comments
Open

On yarn install, and the cache #41

angerman opened this issue Feb 19, 2022 · 2 comments

Comments

@angerman
Copy link

First of all, let me say thank you for this! mkYarnPackage from nixpkgs, had me close to a heart attack.

Now I've found that a lot of javascript folks like to abuse the build and other fields in the package.json, and call out to other packages. Not only do they often then no include those utility packages in the package.json (and yarn.lock) itself 🤯, but this consistently has me writing

        yarnBuild = "yarn install";
        yarnBuildMore = "yarn build";

I'm super happy that buildYarnPackage has this flexibility, it still feels a bit off?


The other issue I've run into is that the offline yarn-cache, generates @bit-mui-org.material-ui.button-base-4.9.10.tgz, for these items:

"@bit/mui-org.material-ui.switch@^4.9.10":
  version "4.9.10"
  resolved "https://node.bit.dev/mui-org.material-ui.switch/-/mui-org.material-ui.switch-4.9.10.tgz#5361dd7d6190d3b2c7134ad38a6436abf077bacd"
  integrity sha1-U2HdfWGQ07LHE0rTimQ2q/B3us0=

and somehow yarn doesn't like that naming scheme? So I end up rewriting them like so:

@bit-mui-org.material-ui.button-base-4.9.10.tgz -> mui-org.material-ui.button-base-4.9.10.tgz

which yarn seems to like. I couldn't find any authoritative answer as to how yarn will end up resolving packages from the offline cache folder. So I'm not even sure this is a good solution :-/ It does work though :(

I now have this rather ugly hack in my package description:

.overrideAttrs (old: {
                        yarnCachePhase = old.yarnCachePhase + ''
                        pushd yarn-cache
                        # strip the "@bit-" part from mui packages. For some reason
                        # yarn's offline cache fails to find them.
                        for pkg in @bit-mui-org*; do echo "$pkg -> ''${pkg:5}"; mv $pkg ''${pkg:5}; done
                        popd
                        '';
                    });

if anyone knows a better solution, I'd be happy to fix this.

@epigramengineer
Copy link

I'll add an example to this. I've been banging my head against a wall trying to build vendure-ecommerce with mkYarnPackage. It technically builds, but fails to run in production because it doesn't install sharp / libvips which is distributed as a prebuilt binary.

yarn create @vendure my-app

Using the flake overlay I've got:

pkgs.buildYarnPackage {
  src = ./my-app;
};

And when I build this I get the following error:

error: builder for '/nix/store/q9585hfn5bhm0ikkk4zgfxhx31lxkgw5-my-app-0.1.0.drv' failed with exit code 1;
       last 10 log lines:
       > Exit code: 1
       > Command: (node install/libvips && node install/dll-copy && prebuild-install) || (node install/can
-compile && node-gyp rebuild && node install/dll-copy)
       > Arguments:
       > Directory: /build/server/node_modules/sharp
       > Output:

warning Cannot find a suitable global folder. Tried these: "/usr/local, /homeless-shelter/.yarn"
       For full logs, run 'nix log /nix/store/q9585hfn5bhm0ikkk4zgfxhx31lxkgw5-server-0.1.0.drv'.

That build command is definitely doing some strange things and I'm not sure how to approach this problem. When I just run yarn install in my local directory all the node_modules are properly populated (specifically node_modules/sharp/build/Release/sharp-linux-x64.node).

My pattern matching is telling me this is the same category of discussion as the original post, but please correct me if I am wrong.

@sbrow
Copy link
Contributor

sbrow commented May 25, 2023

@epigramengineer This is a known issue with yarn, unfortunately. You have to set the $HOME environment variable before calling yarn things.

You can fix this by adding the following to the start of yarnConfigPhase

# this line removes a bug where value of $HOME is set to a non-writable /homeless-shelter dir
export HOME=$(pwd)

I will bundle this up in a PR shortly.

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

3 participants