API fails to build monorepo with yarn workspaces

[jeroenvdmeer]

Describe the bug After repackaging my multirepo project into a monorepo based on yarn workspaces, I noticed the app won't deploy to Azure Static Web Apps anymore. The issue is that when building the Functions app yarn does not pick up one of the dependencies is found in one of the yarn workspace packages. As a result it tries to find the package in the public registry and fails.

To Reproduce See this test repo I've created based on my setup.

Expected behavior Similar to my development setup: after building the Functions app should be able to run.

Screenshots More details can be found in my test repo.

Additional context One part I'm a bit concerned about is that I added a dummy yarn.lock file in the packages/api folder to trigger Oryx to use yarn instead of npm. The lockfile didn't hinder me to build the Functions app locally, but if there are better ways to trigger Oryx to use yarn, I'm happy to give them a try to rule out this could affect the build process.

[anthonychu]

We will be working on a solution for #343 that should work for monorepos where you handle the build yourself. No ETA at the moment but hoping we’ll have something in 2-3 months.

[jeroenvdmeer]

@anthonychu Thanks for your reply. Good to know about the upcoming feature to allow for custom API build steps. Could you share some insights into why the API is unable to build in Oryx? As far as I can tell I'm not doing anything special to successfully build the API locally: running yarn install and yarn build. Understanding what Oryx does differently might give me ideas to circumvent this problem while waiting for #343 to be implemented.

[anthonychu]

We currently treat the app and API folders as completely separate projects. We tell oryx to build them separately. For most monorepos, the install and build commands actually need to be run at the root of the repo, which we don’t support right now.

In your case specifically, it sounds like you needed to trick Oryx into detecting yarn for the API folder.

[gorootde]

I've found a workaround that enables me to build my project which uses yarn workspaces. My directory structure is:

/package.json
/api/package.json
/common/package.json

whereas the api project has a dependency on the common package.

Right before the Azure/static-web-apps-deploy@v1 action, I added

- name: Workaround for oryx not supporting yarn workspaces. See https://github.com/Azure/static-web-apps/issues/542
  run: |
    echo "# This is a fake lock file to trick oryx" > yarn.lock
    sed -i 's/"@myproject\/common": ".*"/"@myproject\/common": "file:..\/..\/common"/g' package.json
  working-directory: api

to my pipeline. This will replace the version number of my common project, with a file path directly pointing to it. Since oryx executes the build in a subfolder, we need to go one more level up than you would usually expect.

[Reshmi-Sriram]

Hey @jeroenvdmeer! A quick update on #343 skip_api_build should now be enabled in GitHub Actions!🎉🎉 In order to use it, we need to set skip_api_build: true in the GitHub workflow yaml and specify the ApiRuntime version in the staticwebapp.config.json file in source repository.

Azure DevOps changes are being merged meanwhile and can be tracked in the following PR

Let us know if this helps in solving your issue :)