Starting from 1.12.1 unable to start medusa

[quiloos39]

Starting from version 1.12.1 i am getting following error when ever i run medusa develop.

I am using yarn monorepo setup with following structure

root
  node_modules/
  packages/
    backend/ -> where medusa resides
      node_modules/
    ...

package.json

{
  "name": "backend",
  "version": "0.0.1",
  "description": "A starter for Medusa projects.",
  "license": "MIT",
  "scripts": {
    "seed": "medusa seed -f ./data/seed.json",
    "build": "babel src -d dist --extensions \".ts,.js\"",
    "start": "medusa start",
    "develop": "medusa develop",
    "migrate": "medusa migrations run",
    "test": "yarn build && jest"
  },
  "dependencies": {
    "@medusajs/admin": "^6.0.2",
    "@medusajs/cache-inmemory": "^1.8.6",
    "@medusajs/cache-redis": "1.8.8",
    "@medusajs/event-bus-local": "^1.9.3",
    "@medusajs/event-bus-redis": "1.8.9",
    "@medusajs/medusa": "1.12.1",
    "@medusajs/medusa-cli": "^1.3.14",
    "@medusajs/medusa-js": "^5.0.0",
    "@sendgrid/client": "^7.7.0",
    "@sendgrid/mail": "^7.7.0",
    "aws-sdk": "^2.1386.0",
    "body-parser": "^1.20.2",
    "email-validator": "^2.0.4",
    "medusa-fulfillment-manual": "^1.1.37",
    "medusa-interfaces": "^1.3.7",
    "medusa-payment-manual": "^1.0.23",
    "medusa-plugin-filestorage-local": "^0.1.2",
    "medusa-plugin-meilisearch": "^2.0.5",
    "mime-types": "^2.1.35",
    "moment": "^2.29.4",
    "multer": "^1.4.5-lts.1",
    "pg-connection-string": "^2.6.0",
    "stripe": "^12.6.0",
    "typeorm": "^0.3.16"
  },
  "devDependencies": {
    "@babel/cli": "^7.18.10",
    "@babel/core": "^7.21.4",
    "@babel/preset-typescript": "^7.21.4",
    "@types/express": "^4.17.17",
    "@types/jest": "^29.5.0",
    "@types/tough-cookie": "^4.0.2",
    "axios": "^1.3.5",
    "axios-cookiejar-support": "^4.0.6",
    "babel-preset-medusa-package": "^1.1.19",
    "jest": "^29.5.0",
    "puppeteer": "^19.8.5",
    "testcontainers": "^9.8.0",
    "tough-cookie": "^4.1.2",
    "typescript": "^5.0.3"
  }
}

Error i am getting

$ medusa develop
Successfully compiled 1 file with Babel (368ms).
node:internal/modules/cjs/loader:1080
  throw err;
  ^
Error: Cannot find module '/home/quiloos39/Documents/traumkaffee/packages/backend/node_modules/@medusajs/medusa/dist/bin/medusa.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1077:15)
    at Module._load (node:internal/modules/cjs/loader:922:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:23:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}
Node.js v18.16.1

I think cause of this is, Medusa started assuming @medusajs/medusa/dist/bin/medusa.js is always at package level as seen from error /home/quiloos39/Documents/traumkaffee/packages/backend/node_modules/@medusajs/medusa/dist/bin/medusa.js. But it's not certain because we don't know depending on other packages it could be either installed at package level or root level so in my case because of medusa was residing in root level it didn't work.

[jono-allen]

We use Medusa in a mono repo using turbo repo, and aswell after upgrading beyond v1.12.0, we get this same error. Reverting to v.1.12.0 resolves the issue.

[jono-allen]

Digging through the changes, the medusa-cli has been converted to typescript, so I wonder if it could be related?

[quiloos39]

Sorry for late answer,

I didn't had time to dig through medusa source code to investigate problem but i have a partial solution. What I did was to use nohoist option in yarn workspaces like bellow, which forces medusa to be installed locally instead of being in root.

// package.json
// ...
"workspaces": {
  "packages": [
    "packages/*"
  ],
  "nohoist": [
    "**/@medusajs",
    "**/@medusajs/**",
    "**medusa**"
  ]
}
// ...

Note: Problem with this approach is if u have any customized version of medusa plugins in your packages directory. You won't be able to use it (i think). Since all services importing base classes from medusa (like TransactionBaseService, NotificationService etc...), i think it's going to cause problems because when nohoist is used it will install medusa separately for each local package. Which will cause plugins to import seperate versions of medusa interfaces.

[jono-allen]

We can start our medusa server with no issues via medusa start but medusa develop fails with the above issue. Can you confirm if the same is for you?

[gempain]

Same here except .bin/babel is not being found. Using turborepo for a monorepo and not able to either start the dev command on the server, or the client. Npm workspaces don't have this hoisting option.

Apart from removing a relative ./node_modules command in the script of the server's package.json, I am trying to understand why those binaries wouldn't being called properly. It looks like npm isn't propagating the bin folder as I'd expect. Seems to be a known issue.

[bentrynning]

I also have this issue and have tried looking through the changes from v 1.12.0 to 1.12.1 v1.12.0...v1.12.1
Not sure why only 1 of the cli commands fails, medusa start and develop is much of the same except that in develop mode it also watches for changes.
But medusa start works as expected even when medusa bin is located at root of monorepo.

[pepijn-vanvlaanderen]

We ran into this issue as well using Turborepo. A workaround we applied for now is to make a symlink:

ln -s <turborepo-root>/node_modules/  <turborepo-root>/apps/medusa/node_modules

Where apps/medusa is the specific app directory we use and can differ per project.

Also not sure if related to this issue, but we needed to install the NPM packages swc-loader and postcss-loader to be able to run the Medusa Admin.

[ripvannwinkler]

As of 1.18.1, this is still an issue. Haven't upgraded recently because of the pain of doing a custom patch every time we do. I had to rework our yarn lock file to debug an issue tonight and encountered the same ceremony again.

Might I suggest the dev CLI use some sort of resolver function to locate the babel and medusa bin commands...something that can traverse parent directories to find them in the root of a monorepo? A workaround is listed above to disable hoisting, but that doesn't work for us because then the custom services we have don't resolve to the same core medusa module and the services don't get loaded properly.

[olivermrbl]

In #5952, we introduced npx to ensure the correct babel executable is found (part of next release). Under the hood, npx will traverse your local node_modules and find the binary. We use the command with the argument --no-install command to avoid installing it remotely if it doesn't exist in your mono or regular repository.

If the executable is missing, something is wrong with your setup, and the issue should be resolved elsewhere – likely by ensuring the CLI (babel, or in this case, medusa) is installed correctly.

Using npx is a simple and effective solution, and we avoid having to maintain a custom script. The cons are that it's slightly slower (seemingly unnoticeable) and gives us less control than a custom script.

I can open a PR and publish a snapshot if you would be up for running a test. Let me know.

Also, if there are any downsides to this approach that I haven't identified, please shout.

[ripvannwinkler]

Sounds like a reasonable solution to me. Can't wait to try it out!

[olivermrbl]

@ripvannwinkler, could I get you to try out these snapshots:

@medusajs/[email protected]
@medusajs/[email protected]

Please note, these will not resolve the issue with the swc-loader in our admin package.

[ripvannwinkler]

@olivermrbl it does appear to run without any patches, but I'm encountering something else weird - might be an artifact of an outdated or missing reference otherwise. When I run medusa develop in the backend project on windows, it tries to open babel.js via the shell command, which triggers a popup asking me which program I want to use to open the file. Whether I cancel the popup, or open in a text editor, the develop command seems to finish executing successfully, but clearly something else is going on. Additionally, my project is in a directory that contains spaces in the name which originally caused the command to fail outright. Maybe needs some work on quoting the commands. I cloned the project to a dir without spaces in the drive root and it worked fine otherwise.

I'll try on my Macbook later to see if the same issue occurs, but any insight you can offer would be helpful.

I also noticed with the 1.19.1 snapshot, typeorm has been replaced by mikroorm. I didn't change anything in our code base to accomodate as this was purely a cli test, but I'm sure that's unrelated to the babel shell open issue mentioned above, as everything appears to run without issue otherwise (nothing extensive on the ORM use in our added services, just a few queries which may need tweaking).

[sradevski]

Hey, thanks for the report! Since v2 brought a lot of architectural and API changes on the backend, we will be closing this ticket since it no longer applies to our new setup, or the issue has already been fixed. If you are still facing issues with v1,
please open a new ticket and we will address it as soon as possible. Thanks! 🙏