Would you be interested in adding a GitHub Codespace to make contributing easier for new devs?

[MarkBennett]

I've been using one of the new GitHub Codespaces for my projects. Basically, it lets you run a Docker container and a full VS Code dev environment right from your browser. You can also connect your locally installed VS Code to the Codespace if you're not into developing in a browser tab.

I've found that this has made it really for new junior devs to get up to speed quickly. It's also let me make changes when I'm not around my laptop.

If there's interest, I'd be happy to make a PR but wanted to check the room before doing that.

[thedavidprice]

Hi @MarkBennett Hellz yeah this would be of interest! We're big fans of Codespaces and know of several Redwood projects/startups using it exclusively.

To clarify what you're suggestion — would this be for 1) developing (contributing) to the framework or 2) developing a Redwood app (e.g. yarn create redwood app) or 3) both?

In case you haven't seen it, we already have an automation set up to create a GitPod.io workspace for every redwoodjs/redwood PR and branch. It's mentioned in our docs here and there's a link in the PR CI checks.

So item 2 above would be of more interest than adding to the existing GitPod option. But honestly we'd be up to follow your lead on this.

Want to get started on a draft PR and loop me, @dac09, and @peterp in? (FYI, I'm going camping this weekend through Monday and Danny is on vacation next week.)

[MarkBennett]

Thanks for the reply @thedavidprice. I don't know how you keep up with GitHub and Twitter as well as everything else you do!

In case you haven't seen it, we already have an automation set up to create a GitPod.io workspace for every redwoodjs/redwood PR and branch. It's mentioned in our docs here and there's a link in the PR CI checks.

I had not seen this, so it appears to serve a similair function. I could certainly supplement with a configuration to re-use the work here with Codespaces so that people have a choice but I'll investigate and provide an update after I've done so. Not sure how much would be re-usable yet.

So item 2 above would be of more interest than adding to the existing GitPod option. But honestly we'd be up to follow your lead on this.

How would you see this working with a new project? Would yarn create redwood-app my-redwood-app include some dotfiles with a codespace setup? Alternatively, would it make sense to provide a generator instead?

Would you like me to canvas on Discourse to see if people would be interested Redwood projects being setup to use Codespaces?

[MarkBennett]

I took a quick look at the .gitpod.yml documentation. It looks similair, but a little different as Codespaces create an environment per developer using the configuration in the project as a starting point. You then switch between branches and work as you normally would using VS Code on your computer.

Why don't I put together a simple PR to enable Codespaces for this project, then I can see the communities feedback on that. If there's a lot of interest, then I can look at adding a generator or config files to new Redwoodjs projects so people can use them for their own applications.

[dac09]

Why don't I put together a simple PR to enable Codespaces for this project, then I can see the communities feedback on that. If there's a lot of interest, then I can look at adding a generator or config files to new Redwoodjs projects so people can use them for their own applications.

@MarkBennett that sounds great! I've just come back from a holiday, happy to help if you need any!

For Redwood projects Although we support gitpod for the framework itself, we don't provide a command for redwood projects either. I'd love to have maybe a generator or setup command for all providers - and having postgres or a DB within the configuration would make things a lot nicer!

For framework dev The purpose of this is to: i) make it easier for anyone to contribute to Redwood with a one-click dev environment ii) make it easier for maintainers (like meeeee) to review PRs, where the generated project uses the framework code from the branch in PR

Unless I'm mistaken though, I don't believe codespaces supports runnning "prebuilds" or would you use a dockerfile to run commands? Roughly speaking the steps we run for gitpod are:

1. Set environment variable RWFW_PATH to point to the framework root
2. yarn install
3. Run yarn run build:test-project $SOME_NEWPATH --typescript --link --verbose where SOME_NEWPATH is the path to generate a new project into

and then finally once all of this is done (takes about 10 mins for yarn installation, then generate a new project from scratch) - we run yarn rw dev in the test project

[thedavidprice]

I suggest the next step here is to focus on Redwood Projects + Codespaces (not Framework).

Having a command like yarn rw setup codespaces would be 💯

@peterp any chance you could share some boilerplate .yml you use (if applicable)?

[virtuoushub]

I suggest the next step here is to focus on Redwood Projects + Codespaces (not Framework).

Having a command like yarn rw setup codespaces would be 💯

@peterp any chance you could share some boilerplate .yml you use (if applicable)?

As a precursor to this, I might suggest to craft a devcontainer.json ( see https://code.visualstudio.com/docs/remote/devcontainerjson-reference )

It can be used with the Remote - Containers extension or GitHub Codespaces.

It also sounds like gitpod will be supporting it in the future.

[edit] PS - happy to help as well. If the devcontainer.json is something we think is worthwhile, the ms-vscode-remote.remote-containers VS Code extension makes creating the boilerplate a breeze via @command:remote-containers.createDevContainerFile

[thedavidprice]

The goal here is to make starting and developing a Redwood app accessible for everyone, regardless of OS, System Specs, Bandwidth, etc. This is why the potential of these virtual dev environments have use very excited.`

To that end, we don't know what is possible or what direction to take. So we need some examples, POCs, strikes... what is possible? And how do these things work?

Lastly, we know GitPod has a generous free tier (50 hours/month). But is Codespaces is still limited — paid for org/team accounts and beta for individuals:

Codespaces is rolling out progressively on August 11th, 2021 and can be enabled in settings by organization owners for Team and Enterprise Cloud plans. For users in individual plans, we’re extending the existing Codespaces beta. For those in the beta, access will remain and we’ll share updates on what’s coming in the near future.

^^ We should keep this in mind as we determine which paths to pursue in the near-term

[MarkBennett]

Lastly, we know GitPod has a generous free tier (50 hours/month). But is Codespaces is still limited — paid for org/team accounts and beta for individuals:

Agreed, this is definitely a limiting factor. I've heard that Google is also working on a "Cloud Editor" as well but they don't seem to have standardized on formatting yet. They're all based on Docker from what I can see so having a standard Dockerfile that prepares a dev environment seems like a good place to start.

[MarkBennett]

As a precursor to this, I might suggest to craft a devcontainer.json ( see https://code.visualstudio.com/docs/remote/devcontainerjson-reference )

Per @virtuoushub 's suggestion, I agree this is a good place to start.

The goal here is to make starting and developing a Redwood app accessible for everyone, regardless of OS, System Specs, Bandwidth, etc. This is why the potential of these virtual dev environments have use very excited.`

So are you suggesting it would make sense to focus on including a .devcontainer and Dockerfile in new projects when people run yarn create redwood-app? Should that be hidden behind a flag, or should those files just be generated by default and people not using Codespaces won't be notified of them?

[MarkBennett]

Codespaces is rolling out progressively on August 11th, 2021 and can be enabled in settings by organization owners for Team and Enterprise Cloud plans. For users in individual plans, we’re extending the existing Codespaces beta. For those in the beta, access will remain and we’ll share updates on what’s coming in the near future.

One other thought on this @thedavidprice... I've actually been using Codespaces with my team for a few years now as you can use them locally on your own box with the VS Code Remote Containers Addon. This let's you use Docker to isolate your dev environment on your own computer. Since we work with many clients that use different stacks I've found it's an easy way to manage all the deps that come with each one and get the team up and running quickly.

[dac09]

So are you suggesting it would make sense to focus on including a .devcontainer

Having .devcontainer by default kind of makes sense to me, especially if its in queue for wider adoption!

and Dockerfile in new projects

I would think this is better off in a setup command yarn rw setup deploy docker

If the devcontainer needs the dockerfile, I think we wouldn't be opposed to introducing a new setup namespace - yarn rw setup dev codespaces, yarn rw setup dev gitpod, etc. Although something better than dev would be nice!

[MarkBennett]

I would think this is better off in a setup command yarn rw setup deploy docker

If the devcontainer needs the dockerfile, I think we wouldn't be opposed to introducing a new setup namespace - yarn rw setup dev codespaces, yarn rw setup dev gitpod, etc. Although something better than dev would be nice!

This seems like a good approach to me.

As I'm putting together some acceptance criteria before I cut a PR, anything else that would be neccesary?

[dac09]

As I'm putting together some acceptance criteria before I cut a PR, anything else that would be neccesary?

1. I think just awareness that the setup commands should be done in a way so that we can support other providers too (stackblitz, gitpod, etc.)
2. Option to set up a database to use along side the actual application (maybe postgres)
3. Awareness of the difference between dockerfiles/compose files for local dev and production deployment

[thedavidprice]

They're all based on Docker from what I can see so having a standard Dockerfile that prepares a dev environment seems like a good place to start.

^^ is this really true for Codespaces? That's not what I understood. And/or maybe you're saying by using Docker we get more options.

We've pulled the thread on and off with Docker and Dockerfiles for a long time now. (And there's a group of people working on it for awhile; see here and here from the forums.) We're now a lot closer to some answers, but there's still complexity here and I'm going to become the annoying bottleneck as soon as we start thinking about a rw setup deploy dockerfile command. Maybe if we focus on a dockerfile that's only intended for dev, this could be simpler and might not be a bottleneck anymore, but people are gonna want to go to Docker Compose... and add a DB service... and Seed... and ...

I'm just already feeling the scope expanding here.

What I'd really like to see as a next step is a POC (because I've yet to see one):

1. a Redwood project, connected to a DB, running in a single solution in the browser (e.g. Gitpod or Codespaces)
   • would need to support SQLite, probably easy peasy
   • but then also should consider Postgres (not necessary within the provider; third part cloud probably fine)
2. the config file to make it happen

Until there's a POC or something to use/try, the PR isn't going to make sense to me.

I'm definitely excited about this. So my thoughts here are primarily just trying to make sure we get somewhere vs. get lost in too many possibilities.

[thedavidprice]

This looks like it's the Codespaces next-step we've been waiting for! https://github.blog/2022-02-23-codespaces-largest-repositories-faster/

And here's a repo we can work on! https://github.com/redwoodjs/redwood-starter