Does this plugin work with yarn workspaces monorepos?

[50bbx]

I have a monorepo managed with Lerna and yarn with a package that is my frontend (which uses Gatbsy) and another that is my CMS (Sanity Studio) both deployed on Netlify.

Here's my lerna.json just for reference

{
  "packages": [
    "packages/A",
    "packages/frontend",
    "packages/B",
    "packages/cms"
  ],
  "version": "independent",
  "npmClient": "yarn",
  "useWorkspaces": true
}

A and B packages are just dependencies of the frontend package.

I tried to think about where should I put my netlify.toml which I didn't need until now. It would look just like this:

[[plugins]]
  package = "netlify-plugin-gatsby-cache"

Do you have any suggestions on where I should put my frontend netlify.toml?

[jlengstorf]

@50bbx I use this plugin with a monorepo for learnwithjason.dev!

I have the netlify.toml in the root and tell it to run commands from inside the site package: https://github.com/jlengstorf/learnwithjason.dev/blob/master/netlify.toml

I haven't worked with Lerna much, but it should be possible for sure!

[slorber]

hi

I also tried this plugin in a monorepo, and it seems to work fine, as it caches assets relative to the publish dir, it's able to understand it should cache a workspace package .cache and /public

---

However I have a problem with monorepo and this plugin. It's not totally related to this plugin though but more about monorepo support in Netlify. How to handle a monorepo where you have like, 2 sites instead of 1, and don't necessarily want this plugin (or other config put at the workspace root) to apply to all sites?

Is there any way to have a single deployment root (the workspace root), and have 2 different netlify toml configs, one for each site, without sharing the build plugins between the 2 deployments? Note, it's the same repo, it's the same branch, it's the same workspace. But there are not always a single site to deploy here (gatsby front, admin CRA, storybook etc...).

Let's take your own website @jlengstorf, how would you do if you had also a storybook to deploy in this workspace? Note using basedir = ./site + toml in subpackage would not work, as Netlify would not understand it's a yarn workspace and actually try to resolve "@jlengstorf/gatsby-theme-code-blog": "*" from npm using npm instead of yarn.

[jlengstorf]

@slorber that's a great question — at the moment I don't think there's a way to selectively apply build plugins in monorepos

@ehmicky will know more than I do here, though, so let me tag him in for comment

[ehmicky]

@slorber My intuition would be set a different base directory (matching the workspace directory) for each Netlify Site and have a different netlify.toml in each of them.

However, if I understood correctly, it seems like this configuration might not work for you based on your comment:

Note using basedir = ./site + toml in subpackage would not work, as Netlify would not understand it's a yarn workspace and actually try to resolve "@jlengstorf/gatsby-theme-code-blog": "*" from npm using npm instead of yarn.

Could you please elaborate on this? Yarn should be used, not npm, providing there is a yarn.lock file in each base directory.

[50bbx]

The problem is exactly that: with yarn workspaces, there is not a yarn.lock in each base directory. There is just one yarn.lock in the root directory.

[jlengstorf]

you can create an empty yarn.lock in the directories that need to build — it won't cause issues with the monorepo, which will ignore it, and Netlify uses the presence of the lockfile to determine with package manager to use

it's kinda hacky, but it will work

[ehmicky]

@50bbx Does the workaround suggested by @jlengstorf works for your use case?

It seems to me this is a more general issue about Yarn workspaces support inside Netlify, beyond this plugin or the Build plugins beta. Therefore I have opened the following issue to make sure our backend team is involved in improving this use case.

If that issue is covering your initial problem, please feel free to close this issue and continue the discussion on that other repository. Thanks!

[sidyes]

I got a similar issue using a lerna (without yarn) monorepo. For deploying I am using a custom script that calls the following commands:

1. lerna bootstrap
2. npm run build

My project under projects/appA has dependency in its package.json called shared-components: "file:../shared-components" which means that I got another project called shared-components within the projects folder. Thus it is not an external dependency but a local one to a shared project.

When using the cache plugin it tries somehow to look for shared-components within the node_modules which obviously does not exist.

Redeploying with clearing the cache in netlify results in a succesful deployment which means that the cache is the problem in this case.

Do you have any suggestions for me of how to fix that?

[jlengstorf]

this issue is beyond the scope of this plugin. I'll be following https://github.com/netlify/build-image/issues/399 and we'll verify upstream fixes once they're merged

[erezrokah]

My project under projects/appA has dependency in its package.json called shared-components: "file:../shared-components" which means that I got another project called shared-components within the projects folder. Thus it is not an external dependency but a local one to a shared project.

Hi @sidyes looks like the correct way to reference local dependencies in lerna when not using yarn is to reference it via the version, e.g. "shared-components": "^1.0.0". See relevant lerna open issue https://github.com/lerna/lerna/issues/2352

I was able to set up this plugin successfully in this repo https://github.com/erezrokah/gatsby-lerna-repo with lerna (without yarn).