docker compose setup fails with superset_node | npm error Cannot read properties of undefined (reading 'extraneous')

[jpchev]

Bug description

I cloned the git code and followed the instructions on the doc page
https://superset.apache.org/docs/contributing/development/#docker-compose-recommended
to setup a dev environment with docker,
but the superset_node container fails and exists with an error,
can you please help me in understanding what I'm doing wrong?

Thank you

**superset_node         | npm error Cannot read properties of undefined (reading 'extraneous')**
superset_node         | npm notice
superset_node         | npm notice New major version of npm available! 10.8.2 -> 11.1.0
superset_node         | npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.1.0
superset_node         | npm notice To update run: npm install -g [email protected]
superset_node         | npm notice

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

I found two similar closed issues related to Docker and npm problems in the Superset repository, but neither provided a solution in the comments ^[1][2].

Regarding your issue, the error message "Cannot read properties of undefined (reading 'extraneous')" in the superset_node container might be related to compatibility issues between Node.js and npm versions. The logs suggest updating npm to version 11.1.0. You can try updating npm within the Docker container by modifying the Dockerfile or using a command like npm install -g [email protected] within the container.

Additionally, ensure that the docker-compose.yaml file is correctly configured. The BUILD_SUPERSET_FRONTEND_IN_DOCKER environment variable should be set to true if you are building the frontend inside the Docker container. If you have less than 16GB of memory, consider setting it to false and running npm install and npm run dev locally for better performance ^[3][4].

If the issue persists, you might want to check the docker-frontend.sh script to ensure it is executing the necessary steps correctly, such as installing npm packages and starting the webpack development server ^[5].

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

[jpchev]

@dosu BUILD_SUPERSET_FRONTEND_IN_DOCKER is undocumented and it's true by default

[dosubot]

The BUILD_SUPERSET_FRONTEND_IN_DOCKER variable being undocumented and defaulting to true can indeed be confusing. If you're experiencing issues with the frontend build, you might want to try setting this variable to false and handle the frontend build locally. This approach can help avoid potential resource constraints and compatibility issues within the Docker container.

To do this, you can:

1. Set BUILD_SUPERSET_FRONTEND_IN_DOCKER=false in your environment variables.
2. Run npm install and npm run dev locally on your machine instead of inside the Docker container.

This setup can often resolve issues related to npm and Node.js version mismatches or resource limitations. If you continue to face issues, ensure your local Node.js and npm versions are compatible with the project's requirements.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

[jpchev]

after pulling again from the master, the error disappeared, but the static resources are not found when loading the web page http://localhost:8088/superset/welcome/

[rusackas]

We need to figure out how to evangelize people using :9000 rather than :8088. We need to document that and the BUILD_SUPERSET_FRONTEND_IN_DOCKER config, so I'll tag @sfirke, but we're welcome to a docs contribution there. Also tagging @mistercrunch as he was weighing options on if/how/where to do forwarding so people can't land on 8088 anymore, since this is a common issue.

[jpchev]

thanks for the info @rusackas actually I was looking at the docker compose and trying to figure out how the service call each other why there are 2 tcp ports exposed.

Now I call http://localhost:9000/ and get the following error in container logs

superset_node         | [HPM] Error occurred while proxying request localhost:9000/ to http://host.docker.internal:8088/ [ENOTFOUND] (https://nodejs.org/api/errors.html#errors_common_system_errors)
superset_db           | 2025-02-28 18:08:06.804 UTC [70] LOG:  checkpoint starting: time
superset_node         | [HPM] Error occurred while proxying request localhost:9000/favicon.ico to http://host.docker.internal:8088/ [ENOTFOUND] (https://nodejs.org/api/errors.html#errors_common_system_errors)

[jpchev]

everything seems to work if I set
superset: "http://superset:8088"
in docker-compose.yml instead of
superset: "http://host.docker.internal:8088

[mistercrunch]

Weird. Wondering why it works for some and not others(?) Also wondering if switching it globally for all would create regressions for people who don't have issues now (?)

[jpchev]

why to call the superset service using host.docker.internal which calls the underlying host network and not directly with superset:8088, which stays in docker virtual network ?

Why to expose the port 8088? That seems to make sense only if the frontend is not running in docker

[mistercrunch]

Seems reasonable - very possible that the people who set it up or altered it didn't know the intricacies around docker/docker-compose networking. Feel free to open a PR improving it.

One thing that's sub-ideal is the fact that docker-compose-image-tag.yml and docker-compose-non-dev.yml are served on 8088, which is inconsistent with docker-compose being on 9000 now. The idea with both of these is to fire up an environment from a pre-built image (as opposed to building from the local checked out repo/branch/ref) to get things running and play with them. We may want to move these use cases to minikube/helm, or collapse the 2 files into one.

Note that @villebro is also planning on exposing a k8s operator to Superset in a different repo, and that acts as an alternative to the helm chart we have today, and would be there to support production use cases.

In any case, we could certainly improve the docs and assets around all this, and clarify the level and mechanisms of support behind each of these. P

ersonally I'm super committed to getting the main docker-compose.yml for devex [developer experience], making it as easy as possible for contributors/committers to have a super solid way to spin up a dev environment on any given github ref, with all the bells and whistles (celery backend, redis for caching, postgres as a solid backend, ....).

The use case for docker-compose-image-tag.yml is "being able to spin up any official baked release to take it on a quick test. drive". That's super important too and can be conflated with the devex use case. Here we don't need all the bells and whistles, and to rebuild everything as systematically as we do to support devex.

Docs could be more explicit and aligned with the person's intent which loosely fall under the 3 use cases:

• I want to set up and environment to do active development and contribute
• I want to take Superset for a quick test drive on my local machine or a sandbox of some kind
• I want to set up a production environment for my organization (k8s, metal, helm-preferred VS k8s operator preferred, ...)