Hacker News Reader

Comment by singhrac | Hacker News Reader

I've tried several boilerplates like SaaSPegasus and one thing I can't really get around is that I feel like the experience of developing in a docker-compose with two build-and-serve containers (e.g. one with gunicorn auto-reload and the other running something like esbuild for the frontend) is very clunky in VSCode?

I feel like I'm doing something crazy, this must be a problem many other people have, but things like language server integration on the JS and Python side separately do not mesh well.

If anyone sees this and has a minimal open source boilerplate to recommend I'd love to try it.

View on HN

So I actually recently dealt with this, sharing this as hopefully it helps you.

https://github.com/ospira/docker-django-react-example

In essence, you need two instances of VSCode running connected to two separate Docker container instances. As I understand it, it's one remote container per VSCode window. Thus, I found this to be best, even though it isn't strictly speaking necessary, but it ends up feeling that way because as you said the language server integration (intellisense and extensions) will not work properly if not connected to the right container.

If you load this up in vs code it should prompt you properly given the presence of the files in `.devcontainter` dir. Having two windows in VSCode is kind of annoying at first, but I found it was actually fine, especially on macOS where tabbing to the other VSCode window (as opposed to ungrouped alt+tab on windows) was painless, and also kept me more organized not having backend and frontend code right next to each other.

Btw, two addendums:

1. I fixed some things in that repo, now it should work out of the box. Apologies if the initial version had some bugs, was taking it out of another project, and the first effort at cleaning it up was too hasty. Note it is still however just meant as an example.

2. You actually can run more than one container per window - see here https://code.visualstudio.com/remote/advancedcontainers/conn.... However, I opted for the double window method because I found that cleaner than toggling between in one window. In my template I assume the two windows method because it will load up the proper subfolder (django or react) of the workspace/monorepo depending on which dev container you connect to.

This was very kind of you, and I’ll give it a shot soon!

Why do you need docker to run esbuild? It’s a static binary.

Not everyone is aware of this fact. I include myself in the list of those who didn't know that. Most likely because I didn't bother to inform myself because my expectation of the JavaScript ecosystem is that you first need to install npm via node, and then have it pull a huge amount of files just to then have a tool with which you can bundle stuff without then understanding where you need to "install" it. It's a chaotic ecosystem, much worse than Python, and I know and love Python.

``` Major features:

- Extreme speed without needing a cache - JavaScript, CSS, TypeScript, and JSX built-in - A straightforward API for CLI, JS, and Go - Bundles ESM and CommonJS modules - Bundles CSS including CSS modules - Tree shaking, minification, and source maps - Local server, watch mode, and plugins ```

No word of it being a single executable, on the landing page, in the "major features"-list.

`npm install --save-exact --save-dev esbuild`. We have different expectations on how to download a binary.

Edit: I found an instruction on how to get the binary [0], why is this so hidden?

[0] https://esbuild.github.io/getting-started/#download-a-build

Nothing is perfect but it's ridiculous to say Node is more chaotic than Python. What's the Python package manager of the month? uv? poetry? pipenv? conda? pip? pyenv? setuptools? virtualenv? venv? pdm? easy_install? pymgr? mamba?

Some only create environments, some only install, some don't even resolve packages, some don't create lock files, some only install python, AND NONE OF THEM agree where to install!

Where does npm install? node_modules and it's been that way from the start.

*I added a fake one to see if people can spot it.

That’s a good question since usually these are built into the docker-compose by default. I think my answer would be that it’s to get the same build environment on my Mac as on prod (i.e. a Linux server), but in practice I don’t think platform-specific details matter.

If that’s the case, why not run Python/gunicorn locally as well, and drop docker entirely?

I wrote about docker development (and a library that solves this for Django here): https://www.reactivated.io/documentation/why-nix/#native-per...

I don't use vscode but never had this kind of problem. Does vscode try to run language servers inside the containers or something? I don't even know how that would work, to be honest. I run language servers outside of containers and it all works just fine.

Reply on news.ycombinator.com