Skip to content

[Bug]: Middleware fails when using NEXT_PUBLIC_MEDUSA_BACKEND_URL environment variable #484

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.

Sign up for GitHub

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

Jump to bottom
Closed
Vallabh-Mahanta opened this issue Apr 24, 2025 · 3 comments · May be fixed by #485
Closed

[Bug]: Middleware fails when using NEXT_PUBLIC_MEDUSA_BACKEND_URL environment variable #484

Vallabh-Mahanta opened this issue Apr 24, 2025 · 3 comments · May be fixed by #485
Assignees
@VariableVic
Labels
bug Something isn't working status: needs triaging wontfix This will not be worked on

Comments

@Vallabh-Mahanta
Copy link

Package.json file

{
  "name": "medusa-next",
  "version": "1.0.3",
  "private": true,
  "author": "Kasper Fabricius Kristensen <[email protected]> (https://www.medusajs.com)",
  "description": "Next.js starter to be used with Medusa server",
  "keywords": [
    "medusa-storefront"
  ],
  "scripts": {
    "dev": "next dev --turbopack -p 8000",
    "build": "next build",
    "start": "next start -p 8000",
    "lint": "next lint",
    "prettier": "prettier --write \"./**/*.{js,jsx,ts,tsx}\"",
    "format": "npm run prettier"
  },
  "resolutions": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "dependencies": {
    "@headlessui/react": "^1.7.17",
    "@hookform/error-message": "^2.0.1",
    "@medusajs/medusa-js": "^6.0.0",
    "@radix-ui/react-dialog": "^1.0.4",
    "@radix-ui/react-dropdown-menu": "^2.0.5",
    "@radix-ui/react-navigation-menu": "^1.1.3",
    "@stripe/react-stripe-js": "^2.1.2",
    "@stripe/stripe-js": "^1.54.2",
    "clsx": "^2.0.0",
    "country-list": "^2.3.0",
    "framer-motion": "^10.16.1",
    "lodash": "^4.17.21",
    "next": "^15.0.3",
    "react": "^18.2.0",
    "react-country-flag": "^3.1.0",
    "react-dom": "^18.2.0",
    "react-hook-form": "^7.45.4",
    "react-icons": "^4.10.1",
    "react-intersection-observer": "^9.5.2",
    "sharp": "^0.32.5",
    "stripe": "^14.8.0",
    "tailwindcss-animate": "^1.0.6",
    "usehooks-ts": "^2.9.1",
    "zod": "^3.22.4"
  },
  "devDependencies": {
    "@types/country-list": "^2.1.2",
    "@types/lodash": "^4.14.197",
    "@types/node": "^20.5.6",
    "@types/react": "^18.2.21",
    "@types/react-dom": "^18.2.7",
    "autoprefixer": "^10.4.15",
    "eslint": "^8.10.0",
    "eslint-config-next": "^15.0.3",
    "eslint-plugin-tailwindcss": "^3.13.0",
    "postcss": "^8.4.29",
    "prettier": "^3.0.2",
    "prettier-plugin-tailwindcss": "^0.5.3",
    "tailwindcss": "^3.3.3",
    "typescript": "^5.2.2"
  }
}

Node.js version

v20.16.0

Operating system name and version

MacOS Sequoia 14.4

Browser name

Chrome

What happended?

The Next.js starter middleware only accepts MEDUSA_BACKEND_URL but not NEXT_PUBLIC_MEDUSA_BACKEND_URL environment variable, causing confusion and errors when setting up the storefront. The middleware throws this error:

Error: Middleware.ts: Error fetching regions. Did you set up regions in your Medusa Admin and define a MEDUSA_BACKEND_URL environment variable? Note that the variable is no longer named NEXT_PUBLIC_MEDUSA_BACKEND_URL.

However, other parts of the codebase use NEXT_PUBLIC_MEDUSA_BACKEND_URL. This means users need to define both variables to get the application working, which is confusing and not well documented.

Expected behavior

The middleware should accept either environment variable name:

MEDUSA_BACKEND_URL (for middleware)
NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY (for client components)

Or at least clearly explain in documentation that both are needed for different parts of the application.

Actual behavior

When only NEXT_PUBLIC_MEDUSA_BACKEND_URL is defined in .env.local (which is what most examples show), the middleware fails with:
Error: Middleware.ts: Error fetching regions. Did you set up regions in your Medusa Admin and define a MEDUSA_BACKEND_URL environment variable? Note that the variable is no longer named NEXT_PUBLIC_MEDUSA_BACKEND_URL.

This happens even though regions are properly set up and accessible via the API directly.

Link to reproduction repo

Clone the repository: git clone https://github.com/medusajs/nextjs-starter-medusa.git
@Vallabh-Mahanta Vallabh-Mahanta added bug Something isn't working status: needs triaging labels Apr 24, 2025
@Vallabh-Mahanta Vallabh-Mahanta mentioned this issue Apr 24, 2025
Open
2 tasks
@VariableVic
Copy link
Collaborator

Hey @Vallabh-Mahanta, where did you find NEXT_PUBLIC_MEDUSA_BACKEND_URL being used elsewhere in the codebase?

We removed the NEXT_PUBLIC_ var to make sure the backend URL isn't exposed to the client.

@Vallabh-Mahanta
Copy link
Author

Hi @VariableVic,

Thanks for getting back to me!
I noticed that NEXT_PUBLIC_MEDUSA_BACKEND_URL is still being used in a few places in the codebase, such as:

www/utils/packages/docs-generator/src/classes/examples/oas.ts

www/apps/api-reference/specs/store/code_samples/JavaScript/auth_customer_%7Bauth_provider%7D_callback/post.js

Both of these reference process.env.NEXT_PUBLIC_MEDUSA_BACKEND_URL to set the backend URL for SDK or API requests in the code samples. I’ve also seen similar patterns in other code samples under
www/apps/api-reference/specs/store/code_samples/JavaScript/.

That’s why I suggested supporting both variables in the middleware—to help avoid confusion for users who come across the NEXT_PUBLIC_ version in the docs or code samples.

I totally understand the concern about exposing backend URLs to the client. If you’d prefer a different way to handle this, or if some of these usages are just legacy and should be cleaned up, I’m more than happy to help update the code or clarify the docs.

Let me know what you think, and thanks again for your guidance!

@VariableVic
Copy link
Collaborator

Hey @Vallabh-Mahanta,

The examples you mentioned appear to be generic ones related to the JS SDK, not specific to the Next.js Starter. As far as I can tell, we no longer reference NEXT_PUBLIC_MEDUSA_BACKEND_URL in the Starter or related docs. This was a deliberate change, so we're not planning to reintroduce support for that public variable.

The Starter should work as expected with just MEDUSA_BACKEND_URL set up. That said, you're of course free to use any environment variables that suit your project setup.

@VariableVic VariableVic added the wontfix This will not be worked on label Apr 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@VariableVic VariableVic

Labels
bug Something isn't working status: needs triaging wontfix This will not be worked on
Projects
None yet
Milestone
No milestone
2 participants
@VariableVic @Vallabh-Mahanta