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

Turbo run start on Azure Linux App Service returns 'Cannot find module '../node-platform'' error #1806

Closed
HQ92 opened this issue Aug 30, 2022 · 2 comments
Labels
needs: triage New issues get this label. Remove it after triage

Comments

@HQ92
Copy link

HQ92 commented Aug 30, 2022

What version of Turborepo are you using?

1.4.3

What package manager are you using / does the bug impact?

Yarn v1

What operating system are you using?

Linux

Describe the Bug

I am trying to run a pruned turborepo app on an Azure Linux App Service. When the server tries to start the app using 'yarn run start' I receive an error where turbo tries to import node-platform but this fails. I can see that node-platform.js exists within the folder 'node_modules/turbo/', but the binary for turbo is being called from 'node_modules/.bin/turbo'.

image

Expected Behavior

I would expect the app service to start as it does on a local system.

To Reproduce

  1. Simple turborepo setup with a react app.
  2. Github action to install, build and deploy to Azure.
  3. Azure App service that does not try to build app, just tries to run it using the yarn version included in yarnrc and .yarn.

I am using Node 16 and Yarn 1.22.19. Turbo 1.4.3.

@HQ92
Copy link
Author

HQ92 commented Aug 30, 2022

The only way I've found around it is by specifying the full path for the turbo module. So instead of 'turbo run start', 'node ./node_modules/turbo/bin/turbo run start' works.

@mehulkar mehulkar added needs: triage New issues get this label. Remove it after triage owned-by: turborepo labels Oct 20, 2023
@anthonyshew
Copy link
Contributor

Seeing that this issue is quite old. I know we've changed some of the things we do to detect the binary's installation since then so I'll close this. If you're still seeing this problem, please open up a fresh issue with a reproduction with the latest canary!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs: triage New issues get this label. Remove it after triage
Projects
None yet
Development

No branches or pull requests

3 participants