Show node_modules & Install Fresh from rails new?

[dee2k22]

Love the general idea and workflow of this Docker setup! However, I have a few issues and questions...

1. I prefer having the node_modules directory visible/accessible as it allows IDEs to index them and suggest a lot more than without them. Additionally, I often like to dive into the sources when I find documentation to be lacking... How would I go about getting the node_modules to appear in my project files? I tried removing the line in the .yarnrc file but then I just end up with permission errors when trying to build in WSL2.
   
   Edit: After re-reading your post, I managed to figure it out... I forgot to edit the Dockerfile to represent my desired node_modules directory location... && mkdir /app/node_modules && chown ruby:ruby -R /app

2. While cloning a git repository can be convenient, it also means I lack the flexibility of using the runtime flags/args that rails new provides. Is there a way to use the Docker files themself as the starting point and run a command to build out a fresh project? Something like docker run exec -rm web rails new . -T -j esbuild -c tailwind -d postgresql?

3. Is there a reason you picked slim-bullseye over an alpine release?

I've been reading your associated blog post and while it's very informative, I'm struggling to understand how to accomplish these two tasks myself and end up with the proper file ownership/permissions inside WSL2...

[nickjj]

Hi,

1. It sounds like you got it after your edit. That's how you could do it.

2. You could generate a new Rails project independent of this project and then diff it vs this project. You could spin up a new Ruby based Docker container, set the volume flag, gem install rails and now you'd have a new fresh Rails project on your system. This workflow is how this project started. There's no way to incorporate all of these repo's changes into a new Rails project.

3. I've been burned in the past a bunch of times with Alpine. It's custom libc implementation isn't compatible with everything and I've noticed in Python applications the runtime performance was worse when interfacing with Postgres. I'm not sure if the same performance hit is present with Ruby but those 2 things alone are enough to make me happily stick with using Debian.

I use WSL 2 here. File permissions are good to go. Everything is owned by my WSL 2 user (not root). Is it different for you?

[jon-price-visiontree]

Hi @dee2k22, I also need to have access to the node_modules folder and I'm wondering how you were able to fix that? I don't quite understand what you did above to make that work. Thanks!

For reference, I'm trying to install vite_rails gem. As part of the installation I need to run bundle exec vite install, but this fails partway because it needs access to the package.json and node_modules folder.

[jon-price-visiontree]

For reference, here's the github repo that I was playing around with before that uses vite_rails and docker.

https://github.com/ElMassimo/vite_rails_docker_example

[nickjj]

In your steps, step 1 and 3 aren't required btw. Both the yarn and bundle install run commands will spin up a fresh container.

In that other repo you linked, Vite is running as a separate container in https://github.com/ElMassimo/vite_rails_docker_example/blob/main/docker-compose.yml.

I don't know what Vite is exactly, is it supposed to be some type of alternative to webpack and esbuild?

[jon-price-visiontree]

Good to know! Still new to docker, so slowly taking it all in.

Ya, I might be over thinking it. What I was trying to do was install and run vite_rails within the container itself, but I'm starting to think that I just need to add another vite service as a separate container that can talk to the web container. What would you recommend?

As far as vite goes, it's another frontend tooling option that replaces webpack and various other bundling tools. It's based on esbuild and really fast. https://vitejs.dev/

[nickjj]

If it's a separate process that watches files for changes like webpack and esbuild then absolutely I would recommend spinning it up as a separate service. It is its own independent process IMO. This repo follows that pattern too. Back when it used Webpacker, that was a separate process and now with esbuild that is its own process. It even splits tailwind into its own process too and both esbuild and tailwind share the same Docker image.

[jon-price-visiontree]

Thanks, I appreciate the information and the help! I'm going to play around with it and see if I can get it up and running as a separate container. Might have more questions for you :)