search

leptos-rs / book

The home for the Leptos book, which can be found deployed at https://book.leptos.dev
MIT License
80 stars 60 forks source link

Dev Container Implementation and README.md Updates #47

Closed Jaffa-Cakes closed 7 months ago

Jaffa-Cakes commented 8 months ago

This PR adds an optional VSCode Dev Container with Docker for a concise, easily rebuildable environment.

It also updates the main README.md file of the repository to reflect this addition with instructions. Please read the new updated README.md for more information and try out this addition.

gbj commented 8 months ago

This pushes the README way too far in the direction of VS Code for my comfort. The process described does not seem to me to be the easiest way to serve the book locally, which is just to install the tools already listed in the README. My experience with adding content like this to READMEs in the past has been that new users interpret it as the only way to do something, and then spread that. (For example, I've seen someone criticize Leptos for its "complicated build process that requires cargo-make," when the use of cargo-make was originally just intended for our CI, and then extended to include running examples.)

As I said on the issue I'm not familiar with Dev Containers but this seems quite opinionated (setting up a default shell with plugins? adding CoPilot?) on a level that's more appropiate to an individual setup.

Jaffa-Cakes commented 8 months ago

This pushes the README way too far in the direction of VS Code for my comfort. The process described does not seem to me to be the easiest way to serve the book locally, which is just to install the tools already listed in the README. My experience with adding content like this to READMEs in the past has been that new users interpret it as the only way to do something, and then spread that. (For example, I've seen someone criticize Leptos for its "complicated build process that requires cargo-make," when the use of cargo-make was originally just intended for our CI, and then extended to include running examples.)

That makes sense, it could be omitted if that is preferred, normally people who work with Dev Containers will notice the .devcontainer directory and understand what to do from there if they like using a containerised environment.

As I said on the issue I'm not familiar with Dev Containers but this seems quite opinionated (setting up a default shell with plugins? adding CoPilot?) on a level that's more appropriate to an individual setup.

Dev Containers are normally intended to include a base and common setup to easily begin development when starting from scratch or not knowing how a project works. In this repository it is not demonstrated to its full potential due to there only being a small number of tools used, however, in instances where more tools are used it can become very useful.

If it is preferred those plugins and Zsh can be removed and users can add them in the VSCode UI as usual if they need them, with all their existing settings ported into their Dev Container from their own VSCode installation. I normally add in Zsh as the bare Debian shell is a little hard on the eyes, it's by no means a requirement though, just a quality-of-life thing.

Would you be interested in merging this if Zsh and the co-pilot extensions were removed? I could carry the same assumptions into any work I do towards leptos-rs/leptos#2189 if we end up moving forward with this on the main Leptos repository as well.

benwis commented 8 months ago

@gbj Perhaps a simplified version of this could be linked to from the README(maybe with a disclaimer) and added to the Book as its own section. Then people can find it and we have some docs for it?

diversable commented 8 months ago

If it is preferred those plugins and Zsh can be removed and users can add them in the VSCode UI as usual if they need them, with all their existing settings ported into their Dev Container from their own VSCode installation. I normally add in Zsh as the bare Debian shell is a little hard on the eyes, it's by no means a requirement though, just a quality-of-life thing.

Would you be interested in merging this if Zsh and the co-pilot extensions were removed?

it's not a bad idea to have a minimal dev container available as an option. imho it should be described clearly as an alternative, though, not the preferred method of reading or contributing to the book (the book is easy to read online; a local install is really only necessary if you wish to make changes to the book).

benwis commented 7 months ago

This looks good to me, thanks for contributing!