worker docker container fails to start in local dev about stacker.news HOT 5 CLOSED

I think we probably just need to regenerate the package-lock.json if only platform specific packages are being installed.

It appears there's a bug in npm around this: npm/cli#4828

from stacker.news.

I am trying this approach which looks promising. I'll report back here with results.

from stacker.news.

Here's an update. Putting the following into docker-compose.override.yml seems to have fixed the issue:

version: "3"
services:
  worker:
    command:
      - npm install @esbuild/[email protected] --no-save --loglevel verbose && npm run worker:dev

The diff is

- npm run worker:dev
+ npm install @esbuild/[email protected] --no-save --loglevel verbose && npm run worker:dev

--no-save is critical because this is what omits updating package.json and package-lock.json, meaning the git tree remains clean.

I can open a PR to make this change into docker-compose.yml, if you think that's a good idea @huumn? I assume this is only an issue for developers not using linux locally, so @ekzyis is probably unaffected.

Thoughts? Opinions? Open to feedback :)

Edit: Another note, this is pretty hacky because the specific version 0.18.20 is required to match what's in package-lock.json for esbuild, otherwise the worker will fail at runtime. So if we go this route, you'd have to keep the versions in sync.

According to npm why, we have this dependency due to tsx:

npm why @esbuild/linux-x64   
@esbuild/[email protected]
node_modules/@esbuild/linux-x64
  optional @esbuild/linux-x64@"0.18.20" from [email protected]
  node_modules/esbuild
    esbuild@"~0.18.20" from [email protected]
    node_modules/tsx
      tsx@"^3.13.0" from the root project

Perhaps we could remove tsx from our dependency tree to avoid this? Or we could invoke it via npx e.g. npx tsx so the deps aren't in package.json at all?

from stacker.news.

I've encountered this issue too. If you don't run npm install locally before running sndev start it won't create issues.

Is there a reason you install on the host before starting the environment?

The ideal solution here imo is to not share /node_modules with the host, and have npm use a non-standard location for node_modules in the app container.

from stacker.news.

Is there a reason you install on the host before starting the environment?

Habit, I guess? I suppose it's not required for local development, then? It's definitely an oddity though because package-lock.json indicates the darwin-arm version of the dependencies, which I assume came from your local install (macOS on apple silicon)?

The ideal solution here imo is to not share /node_modules with the host, and have npm use a non-standard location for node_modules in the app container.

I can experiment with that. I do think there is an issue with checking in tsx though, based on the above regarding having package-lock.json include the platform-specific version.

Perhaps we could use npx tsx@<specific version> to pin ourselves to the version we're currently using, to remove concern with affecting production, and also not having it represented in package-lock.json? I can explore not sharing node_modules, too.

from stacker.news.