Fix Docker and upgrade Node

[gabalafou]

This PR builds on #412 and does the following:

• Uses Corepack in GitHub workflows, Dockerfile, and other places to ensure that the version of Yarn specified in package.json is used.
  • Why: Using one version of Yarn in one place, but a different version of Yarn in another can cause various local or CI workflows to fail (dev, release, etc.)
• Specifies that the minimum supported version of Node.js is now v20 instead of v18
  • Why: Still allows people to install and run the app with 18, but makes it clear that we are only officially supporting versions 20 and above, which reduces potential maintenance burden for us
• Updates the Node version used across GitHub CI jobs and dev environments to v22
  • Why: this is the latest even version of Node.
• Changes the Docker Compose file to only mount the folders containing application source code, not the entire repo.
  • Why: This was causing one of the dev setups to fail. The failing setup was the one in which conda-store-ui runs in a Docker container. (See below for explanation.)
• Deletes environment setup instructions in the README. Points contributors to a future page in the Conde Store docs. I opened a PR for this future docs page (on top of another PR). So this PR should not be merged until both 📝 Update local-setup-ui.md pavithraes/conda-store#6 and [DOC] Update contributing guidelines conda-store#763 are merged.
  • Why: There should be a single-source of truth for the instructions, otherwise it will be easy for them to diverge from each other in the future.

About the bug and Yarn

My initial pass at this PR tried to downgrade Yarn based on the following false assumption:

I realized that trying to use Yarn 4 was causing a very hard to debug error when trying to run conda-store-ui in Docker, something about node_module state file.

Later, I realized that the real source of the error was in the Docker Compose file. First, Docker Compose would build the Docker image according to the Dockerfile, which does yarn install, which creates the node_modules folder inside the Docker image. Next, Docker Compose would bind-mount the entire repo root directory to the conda-store-ui Docker container, thus undoing the yarn install step. This is because yarn install was not run locally, so the local directory has no node_modules directory. So then when the local directory is mounted to the container directory, it effectively deletes the node_modules directory.

[gabalafou]

self review

[gabalafou]

This command doesn't actually exist anymore but it was never updated. Probably because the image is never run with this default command but rather a command override is supplied by Docker Compose.

[gabalafou]

Can't actually pass these options this way.

[gabalafou]

These are really the only folders that can be watched for hot-reloading. Mounting everything was causing the .env file (which gets copied in the build step, see the Dockerfile) to go missing.

[gabalafou]

Changing the yarn version back three version caused the entire yarn lockfile to be rewritten

[gabalafou]

In other words, this change is to be expected.

[gabalafou]

Not needed for Yarn classic (v1)

[gabalafou]

See https://github.com/pavithraes/conda-store/pull/6/files#diff-92e0b9d303642f734c7d2ce9858f4d52d2969a01a240295032464e742b3d599dR57

[trallard]

Follow-ups

The Dockerfile implicitly uses the version of Yarn that comes bundled with the node:18.18-alpine3.18 image, which is Yarn v1.22.19.

In our package.json we have "node": ">=18.0.0" so it is perhaps a good idea to bump the base image to [22.8.0-alpine3.20](https://hub.docker.com/layers/library/node/22.8.0-alpine3.20/images/sha256-85235be9f710c1ca817cb67892544b7f0cf994ef05380e8ac0d2ea58dce8a988?context=explore) if we want to stick to alpine images. But see below...

So I decided it will make things simpler if we just use Yarn 1.22.19.

I am not a massive fan of alpine-based images, this might have been chosen for size but we could change the base to match the base we have in conda-store to provide consistency across both setups and that removes the need to downgrade yarn here.

[gabalafou]

This was the real source of the "node_modules state file not found" error, not the Yarn version

[gabalafou]

Using Corepack now, not yarnPath, so this file should be deleted

[gabalafou]

Added the --immutable flag here as a precaution. The Docker build will fail if the Yarn install process would result in a different yarn.lock file, which could happen for example if two different versions of Yarn are used.

[gabalafou]

@trallard it was good of you to push back against the Yarn downgrade. It wasn't necessary. The real culprit of the bug I was trying to solve was in the volumes key in the Docker Compose file (see diff).

I created two follow-up issues:

1. [ENH] - Bump to latest Node.js #416
2. Match Docker base image with conda-store repo #417

[trallard]

I left a few comments and a couple of nits, but overall this is in a much better place now, thank you!

[trallard]

My only hesitation about pinning on the conda environment, as listed before, is that with hard pins, one has to be quite disciplined about updating them regularly. Otherwise, one misses out on security updates and the like.

I know this is true of the Docker image too, but unless it is infra/core system deps or to avoid hard incompatibilities then it is best to not add a hard pin to major.minor

[trallard]

I think this is pretty much ready but until @pavithraes's PR is merged I will mark this as do not merge

[gabalafou]

Could this get another review?

There are two important changes since the last review.

In Dockerfile:

-FROM node:22.8.0-alpine3.20
+FROM node:22-alpine

In Conda environment_dev.yml:

-- nodejs=22.8.0
+- nodejs=22

[gabalafou]

I decoupled this PR from @pavithraes's PR. Now it points to the current docs page on UI development. These instructions are just as accurate as the current repo readme (which is to say pretty accurate except that there is a missing yarn install step in the Docker instructions that actually shouldn't be there because it's really the Docker Compose config that needs to be fixed and which this PR does fix, the issue with bind-mounting the entire repo directory versus the two directories with watchable source files).

I left a comment on conda-store#763 that a follow-up task to 763 is to update the link in the conda-store-ui readme.

As such, I am going to remove the DO-NOT-MERGE label.