Fixes#452
When the empty state is rendered with a non-textual element (which it turns out all our current empty states are, because they have a `<button />` component as a call to action), this noisy error log was showing up in the `console`:
```
Warning: validateDOMNesting(...): <div> cannot appear as a descendant of <p>.
at div
at div
at p
at Typography (webpack-internal:///./node_modules/@material-ui/core/esm/Typography/Typography.js:166:28)
at WithStyles (webpack-internal:///./node_modules/@material-ui/styles/esm/withStyles/withStyles.js:64:31)
at div
at StyledComponent (webpack-internal:///./node_modules/@material-ui/styles/esm/styled/styled.js:95:28)
at EmptyState (webpack-internal:///./src/components/EmptyState/index.tsx:47:25)
...
at ProjectsPage (webpack-internal:///./src/pages/projects/index.tsx:37:18)
at Routes (webpack-internal:///./node_modules/react-router/index.js:275:5)
at ThemeProvider (webpack-internal:///./node_modules/@material-ui/styles/esm/ThemeProvider/ThemeProvider.js:44:24)
at UserProvider (webpack-internal:///./src/contexts/UserContext.tsx:100:55)
at SWRConfig$1 (webpack-internal:///./node_modules/swr/dist/index.esm.js:501:23)
at Router (webpack-internal:///./node_modules/react-router/index.js:209:15)
at BrowserRouter (webpack-internal:///./node_modules/react-router-dom/index.js:118:5)
at App
```
The issue was that the `description` prop could either be a `string` or an actual `React` component, but was always rendered as a child of a `<Typography />` component. The `<Typography>` component internally renders as a `<p>`, which is not valid to nest `<div>`s inside.
The fix is to not nest inside a `<Typography />` block, but an actual `<div />`.
While going through the manual CLI flow with some people on the team, there was some confusion with the `coder daemon` command - the fact there was no output to confirm that the daemon started:
```
coder ~/coder (bryphe/fix/daemon-log) $ dist/coder_linux_amd64/coder daemon
```
This PR just adds a simple log to confirm that the daemon has started:
```
coder ~/coder (bryphe/fix/daemon-log) $ dist/coder_linux_amd64/coder daemon
2022-03-16 17:57:20.358 [INFO] <daemon.go:53> daemon started {"url": "http://127.0.0.1:3000"}
```
Just throwing this out there. Feel free to reject if you have concerns about adding this @kylecarbs !
This refactoring re-organizes the `site` folder to have a nested `src` folder.
Originally, [we wanted to keep the directory structure shallow](https://github.com/coder/coder/pull/8#issuecomment-1009578910) - but there were two points that motivated this change to introduce the `src` level.
1. We have several non-`src` folders now (`e2e`, `static`, `html_templates`, `.storybook`)
2. Having a `src` folder makes it easier to run XState Typegen
So given those two data points - I believe it makes sense to revisit that and introduce a `src` folder.
This adds a couple of missing pieces to the docs:
- More info about `./develop.sh`
- Steps to run the built coder binary manually
- Starting the server
- Logging in
- Creating a project
I attempted to keep them relatively agnostic so they wouldn't be out of date immediately when https://github.com/coder/coder/pull/422 is merged
@presleyp noticed that we have a lot of dependencies listed as `devDependencies` that should be actual `dependencies` - this PR moves them to the appropriate category.
Thanks for catching this @presleyp !
I was investigating some of the test failures in https://github.com/coder/coder/pull/429 - and realized that we actually don't need the `http-proxy-middleware` package anymore (or the `express` package). Of course - the failures were unrelated to that change, so this doesn't fix the CI failures that were encountered.
`http-proxy-middleware` and `express` were needed for our custom NextJS dev server, but that code was removed in #348 , so those dependencies are no longer explicitly required. We should just remove them to avoid the maintenance overhead.
Another clean-up / follow-up from #348
This fixes#433 - a test flake in E2E (intermittent `ESOCKETTIMEDOUT` errors on MacOS).
The main issue is that, occasionally, for very large dependencies (like `@material-ui/icons`) - yarn can actually time out! We researched this in-depth in v1: https://github.com/coder/m/pull/10040 and fixed it successfully there, by increasing the timeout for yarn.
However, this also highlighted the fact that our `node_modules` caching behavior wasn't correct - we should very rarely see a timeout issue like this, because `@material-ui/icons` should be cached.
It turns out that we weren't falling back to the latest cached `node_modules` if there was a miss - so anytime the lock file changed, we'd invalidate the cache, and not restore the previous one. This can be improved by using the [`restore-keys`](https://github.com/coder/m/pull/10040) parameter of the [`@actions/cache`](https://github.com/actions/cache)... and in fact we already do this for the `go` dependencies.
So this fix does two things:
- Improve the caching behavior, such that we should rarely have to install `@material-ui/icons` (and other large dependencies)
- When we do have to install, update the timeout so that we can avoid random `ESOCKETTIMEDOUT` errors
Fix for #348 - migrate our NextJS project to a pure webpack project w/ a single bundle
- [x] Switch from `next/link` to `react-router-dom`'s link
> This part was easy - just change the import to `import { Link } from "react-router-dom"` and `<Link href={...} />` to `<Link to={...} />`
- [x] Switch from `next/router` to `react-router-dom`'s paradigms (`useNavigation`, `useLocation`, and `useParams`)
> `router.push` can be converted to `navigate(...)` (provided by the `useNavigate` hook)
> `router.replace` can be converted `navigate(..., {replace: true})`
> Query parameters (`const { query } = useRouter`) can be converted to `const query = useParams()`)
- [x] Implement client-side routing with `react-router-dom`
> Parameterized routes in NextJS like `projects/[organization]/[project]` would look like:
> ```
> <Route path="projects">
> <Route path=":organization/:project">
> <Route index element={<ProjectPage />} />
> </Route>
> </Route>
> ```
I've hooked up a `build:analyze` command that spins up a server to show the bundle size:
<img width="1303" alt="image" src="https://user-images.githubusercontent.com/88213859/157496889-87c5fdcd-fad1-4f2e-b7b6-437aebf99641.png">
The bundle looks OK, but there are some opportunities for improvement - the heavy-weight dependencies, like React, ReactDOM, Material-UI, and lodash could be brought in via a CDN: https://stackoverflow.com/questions/50645796/how-to-import-reactjs-material-ui-using-a-cdn-through-webpacks-externals
This brings an initial E2E test (really, an integration test - it's only running the server locally, as opposed to against a deployment - but it'd be easy to point playwright to a deployment).
Demo gif:
This test exercises a minimal flow for login:
- Run the `coderd` binary to start a server on 3000
- Create an initial user as part of setup
- Go through the login flow and verify we land on the projects page
It will be useful to have to ensure that #360 doesn't introduce a regression in the login flow
Future E2E tests that would be useful:
- Create a project & verify it shows in the UI
- Create a workspace and verify it shows in the UI
While going through the create projects flow, I realized there's a typo on the projects page.
The command should read `coder projects create`, but instead it is currently showing `coder project create`:
<img width="466" alt="Screen Shot 2022-03-01 at 5 31 19 PM" src="https://user-images.githubusercontent.com/88213859/156277646-6fc03977-6dda-4db4-9fce-e48b4b5efba3.png">
Fixing this typo will alleviate some confusion as we on-board developers to v2
Noticed while running through the build steps (`make build`) that we were getting some lint warnings that weren't blocking build:
```sh
./pages/workspaces/[user]/[workspace].tsx
32:58 Warning: Unexpected any. Specify a different type. @typescript-eslint/no-explicit-any
32:96 Warning: Unexpected any. Specify a different type. @typescript-eslint/no-explicit-any
./components/Form/FormCloseButton.tsx
26:6 Warning: React Hook useEffect has a missing dependency: 'onClose'. Either include it or remove the dependency array. If 'onClose' changes too often, find the parent component that defines it and wrap that definition in useCallback. react-hooks/exhaustive-deps
./components/Navbar/UserDropdown.tsx
38:14 Warning: Unnecessary conditional, value is always truthy. @typescript-eslint/no-unnecessary-condition
68:10 Warning: Unnecessary conditional, value is always truthy. @typescript-eslint/no-unnecessary-condition
./components/Redirect.tsx
20:6 Warning: React Hook useEffect has missing dependencies: 'router' and 'to'. Either include them or remove the dependency array. react-hooks/exhaustive-deps
./components/SignIn/SignInForm.tsx
126:19 Warning: Unnecessary optional chain on a non-nullish value. @typescript-eslint/no-unnecessary-condition
```
It turns out our ESLint config wasn't being picked up, so I fixed that (it wasn't properly named). This PR turns warnings-as-errors on, fixes the issues, and also removes the "Project Create" page, because it isn't used at this time.
Wanted to clean this up before on-boarding more FE developers
Thought it'd be helpful to show a bare-bones example of a project with a parameter, along with references to the Terraform docs so developers can learn about more interesting variable types (and ways to leverage them in expressions).
With this project, we can go through the `projects create` flow of setting a parameter:
<img width="677" alt="Screen Shot 2022-02-18 at 7 53 07 PM" src="https://user-images.githubusercontent.com/88213859/154785203-ab626268-0e51-48c3-b374-3d49d541042b.png">
I was thinking it might be nice to have some example projects (especially as we on-board new developers) to make it easy to create new projects.
This adds the most basic possible terraform module... just an output block. However, it's enough to run `coder projects create` and go through the whole lifecycle of creating a project and workspace (although, it's really boring since there are no parameters).
Fixes#210 - this isPR implements `coder login` in the case where the default user is already created.
This change adds:
- A prompt in the case where there is not an initial user that opens the server URL + requests a session token
- This ports over some code from v1 for the `openURL` and `isWSL` functions to support opening the browser
- A `/api/v2/api-keys` endpoint that can be `POST`'d to in order to request a new api key for a user
- This route was inspired by the v1 functionality
- A `cli-auth` route + page that shows the generated api key
- Tests for the new code + storybook for the new UI
The `/cli-auth` route, like in v1, is very minimal:
<img width="624" alt="Screen Shot 2022-02-16 at 5 05 07 PM" src="https://user-images.githubusercontent.com/88213859/154384627-78ab9841-27bf-490f-9bbe-23f8173c9e97.png">
And the terminal UX looks like this:
This is just a quick fix so that the redirection is correct after creating a workspace - so that we make it to our minimal 'workspaces' page. Mainly so we have a path for testing / onboarding more people.
Unfortunately the NextJS pages are a bit tricky to test - we don't have infra for it because of the special pathing requirements - we can potentially bring in a library like [next-page-tester](https://github.com/next-page-tester/next-page-tester) and create a separate test directory like `pages_test` - but since we may pick up the RFC to move away from Next, it doesn't seem like a useful effort.
With this, creating a project lands on our minimal workspaces page, and the links on the Projects page correctly navigate to the minimal workspaces page.
Fixes#304
Unblocks #298
After logging in, the login flow should redirect to a whatever path is specified by the `?redirect` query parameter. This is important for cases like #298 - where we need to set `?redirect=%2Fcli_auth`, but also really any case where the user is linked and might have to go back to the login screen.
The fix is simple - just check if the `redirect` query parameter is set, and if it is, use that as the path to redirect to on success. Also adds a test case - we had one checking that we redirect to the default (root `/`) url, but not one of the `?redirect` param
Fixes#291 - renames the `expect` go package to `console`, and changes the api from `expect.NewTestConsole` to `console.New`, and a few other small changes to support the linter (ie, `ConsoleOpts` -> `Opts`)
In v1, we had a quick and easy way to leave creation forms - an escape button (and key handler) in the top right corner.
This was especially helpful in cases where the form was long enough that the 'Cancel' button was off-screen.
This ports over that component into v2 and hooks up into our two existing forms:
<img width="977" alt="Screen Shot 2022-02-09 at 5 48 03 PM" src="https://user-images.githubusercontent.com/88213859/153321503-af957f2b-d674-4ebf-9ac5-97939cb9153f.png">
In addition, this adds test cases + a storybook story for it.
This brings together a bunch of random, partially implemented packages for support of the new(ish) Windows [`conpty`](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/) API - such that we can leverage the `expect` style of CLI tests, but in a way that works in Linux/OSX `pty`s and Windows `conpty`.
These include:
- Vendoring the `go-expect` library from Netflix w/ some tweaks to work cross-platform
- Vendoring the `pty` cross-platform implementation from [waypoint-plugin-sdk](https://github.com/hashicorp/waypoint-plugin-sdk/tree/b55c787a65ff9b7d2b32cfae80681b78f8f2275e/internal/pkg/pty)
- Vendoring the `conpty` Windows-specific implementation from [waypoint-plugin-sdk](https://github.com/hashicorp/waypoint-plugin-sdk/tree/b55c787a65ff9b7d2b32cfae80681b78f8f2275e/internal/pkg/conpty)
- Adjusting the `pty` interface to work with `go-expect` + the cross-plat version
There were several limitations with the current packages:
- `go-expect` requires the same `os.File` (TTY) for input / output, but `conhost` requires separate file handles
- `conpty` does not handle input, only output
- The cross-platform `pty` didn't expose the full set of primitives needed for `console`
Therefore, the following changes were made:
- Handling of `stdin` was added to the `conpty` interface
- We weren't using the full extent of the `go-expect` interface, so some portions were removed (ie, exec'ing a process) to simplify our implementation and make it easier to extend cross-platform
- Instead of `console` exposing just a `Tty`, it exposes an `InTty` and `OutTty`, to help encapsulate the difference on Windows (on Linux, these point to the same pipe)
Future improvements:
- The `isatty` implementation doesn't support accurate detection of `conhost` pty's without an associated process. In lieu of a more robust check, I've added a `--force-tty` flag intended for test case use - that forces the CLI to run in tty mode.
- It seems the windows implementation doesn't support setting a deadline. This is needed for the expect.Timeout API, but isn't used by us yet.
Fixes#241
Fixes#244
- Adds `jest-junit`
- Configures `jest-junit` to output `junit.xml` in `site/test_results`
- Uploads the emitted `junit.xml` to datadog as part of the `test/js` workflow
This adds a `make install` target that copies the CLI and other coder binaries to `$GOPATH/bin` Intended to be helpful for developers who aren't familiar with `go` or the directory structure, in running `coder` CLI locally.
I noticed when showing the development flow to a few engineers, there was one awkward step - you have to `cd site` and run `yarn install`, and then come back to root to `make build` or `./develop.sh`
This just adds `yarn install` as part of `make build` and `./develop.sh` - so whichever one is run first will start work.
While working on the projects page, I noticed the `/projects` endpoint would return 'null' instead of an empty array. An empty array would simplify the behavior on the client page.
There were already tests in place for this, but they only validated that the item's length is 0... and it turns out `len(nil)` is also `0`.
So this does a couple things:
- Updates the empty-project tests to check for `NotNil` as well
- Update the project endpoints to return an empty array if no rows are returned
- Remove the hack in `/projects` page for populating data, as it is no longer needed
Since we're using GH issues to track work (thanks @misskniss and @tjcran for setting this up!) - we probably don't want the stale bot to close untouched issues every month 😬
I considered using a separate stale-duration (like, 365 days for issues) - but just turned it off now. Easy for us to change if we want to adjust the process.
An issue came up last week... our `embed.go` strategy doesn't handle dynamic NextJS-style routes! This is a blocker, because I'm aiming to set up CD on Monday, and the v2 UI makes heavy use of dynamic routing.
As a potential solution, this implements a go pkg `nextrouter` that serves `html` files, but respecting the dynamic routing behavior of NextJS:
- Files that have square brackets - ie `[providers]` provide a single-level dynamic route
- Files that have `[[...` prefix - ie `[[...any]]` - are catch-all routes.
- Files should be preferred over folders (ie, `providers.html` is preferred over `/providers`)
- Fixes the trailing-slash bug we hit in the previous `embed` strategy
This also integrates with `slog.Logger` for tracing, and handles injecting template parameters - a feature we need in v1 and v2 to be able to inject stuff like CSRF tokens.
This implements testing by using an in-memory file-system, so that we can exercise all of these cases.
In addition, this adjust V2's `embed.go` strategy to use `nextrouter`, which simplifies that file considerably. I'm tempted to factor out the `secureheaders` logic into a separate package, too.
If this works OK, it could be used for V1 too (although that scenario is more complex due to our hybrid-routing strategy). Based on our FE variety meeting, there's always a chance we could move away from NextJS in v1 - if that's the case, this router will still work and be more tested than our previous strategy (it just won't make use of dynamic routing). So I figured this was worth doing to make sure we can make forward progress in V2.
This just adds a very simple dockerfile for deploying `coderd` (and later `provisionerd`).
This adds a `deploy` directory at the root, and a `make docker/build` command to the makefile.
Thanks @jawnsy for the all the help 😄
This hooks up `storybook`, which the front-end team has enjoyed using in the v1 codebase - it makes it quick and easy to view and test components in isolation.
The `<LoadingButton />` has a simple story added now, so if you run `yarn storybook`, you can preview it in various states:
This will be helpful as we bring more front-end devs to help build v2 out.
Unfortunately along with #133 I missed one other item in moving files to `/site` in #128 - ignoring new configuration files (and other folders) in our `jest.config.js`.
This caused our coverage numbers in front-end code to dip, because files that shouldn't be included (and previously weren't included) were now being tracked for coverage.
Missed in #128 - need to update the `dependabot.yml` to point to the correct package.json, which was moved from `/package.json` -> `/site/package.json`
This refactors the front-end collateral to all live within `site` - so no `package.json` at the root.
The reason we had this initially is that the jest test run and NextJS actually require having _two_ different `tsconfig`s - Next needs `jsx:"preserve"`, while jest needs `jsx:"react"` - we were using `tsconfig`s at different levels at the hierarchy to manage this.
I changed this behavior to still use two different `tsconfig.json`s, which is mandatory - but just side-by-side in `site`.
Once that's fixed, it was easy to move everything into `site`
Follow up from: https://github.com/coder/coder/pull/118#discussion_r796244577
@kylecarbs and I were debugging a gnarly postgres issue over the weekend, and unfortunately it looks like it is still coming up occassionally: https://github.com/coder/coder/runs/5014420662?check_suite_focus=true#step:8:35 - so thought this might be a good testing Monday task.
Intermittently, the test would fail with something like a `401` - invalid e-mail, or a `409` - initial user already created. This was quite surprising, because the tests are designed to spin up their own, isolated database.
We tried a few things to debug this...
## Attempt 1: Log out the generated port numbers when running the docker image.
Based on the errors, it seemed like one test must be connecting to another test's database - that would explain why we'd get these conflicts! However, logging out the port number that came from docker always gave a unique number... and we couldn't find evidence of one database connecting to another.
## Attempt 2: Store the database in unique, temporary folder.
@kylecarbs and I found that the there was a [volume](https://github.com/docker-library/postgres/blob/a83005b407ee6d810413500d8a041c957fb10cf0/11/alpine/Dockerfile#L155) for the postgres data... so @kylecarbs implemented mounting the volume to a unique, per-test temporary folder in https://github.com/coder/coder/pull/89
It sounded really promising... but unfortunately we hit the issue again!
### Attempt 3... this PR
After we hit the failure again, we noticed in the `docker ps` logs something quite strange:
When the docker image is run - it creates two port bindings, an IPv4 and an IPv6 one. These _should be the same_ - but surprisingly, they can sometimes be different. It isn't deterministic, and seems to be more common when there are multiple containers running. Importantly, __they can overlap__ as in the above image.
Turns out, it seems this is a docker bug: https://github.com/moby/moby/issues/42442 - which may be fixed in newer versions.
To work around this bug, we have to manipulate the port bindings (like you would with `-p`) at the command line. We can do this with `docker`/`dockertest`, but it means we have to get a free port ahead of time to know which port to map.
With that fix in - the `docker ps` is a little more sane:
...and hopefully means we can safely run the containers in parallel again.
Previously, there was a pseudo-workspaces page that was leftover from prototyping, but doesn't make sense in the revised flow.
Now, we have a `/projects` page, and after logging in, the user should be taken to that page:
This implements a client-side redirect to land on our `/projects` route.
Prompted from discussion here: https://github.com/coder/coder/pull/60/files#r792124373
Our current FormTextField implementation requires a [higher-order component](https://reactjs.org/docs/higher-order-components.html), which can be complicated to understand.
This experiments with moving it to not require being a HoC.
The only difference in usage is that sometimes, you need to provide the type like `<FormTextField<FormValues> form={form} formFieldName="some-field-in-form" />` - but it doesn't require special construction.
This implements a simple Project listing page at `/projects` - just a table for a list of projects:
...and an empty state:
There isn't too much data to show at the moment. It'll be nice in the future to show the following fields and improve the UI with it:
- An icon
- A list of users using the project
- A description
However, this brings in a lot of scaffolding to make it easier to build pages like this (`/organizations`, `/workspaces`, etc).
In particular, I brought over a few things from v1:
- The `Hero` / `Header` component at the top of pages + sub-components
- A `Table` component for help rendering table-like UI + sub-components
- Additional palette settings that the `Hero`
#37 implemented the Sign-_in_ flow, but there wasn't a Sign-_out_ flow as part of that PR (aside from letting the cookie expire... or manually deleting the cookie...), which is obviously not ideal.
This PR implements a basic sign-out flow, along with a very simple user dropdown:
Bringing in a few pruned down components for the `<UserDropdown />` to integrate into the `<NavBar />`.
In addition, this also implements a simple back-end API for `/logout` which just clears the session token.
While I was testing the Sign-out functionality in #46 , I found a bug on login.
Sometimes, intermittently, the login wouldn't 'take' even though the login POST was successful and the subsequent GET to `/api/v2/user` was successful - the user would still be brought to the `/login` screen a second time:
^ I log-in, and then the login screen just resets, and logging in a second time works 🤔
I tracked this down and found it is a new race condition that I inadvertently introduced when I migrated to SWR in #46. Because SWR caches responses based on the API path - we have to invalidate the cache for `/api/v2/user` when the user logins, otherwise we'll continue to serve the user-not-found error until SWR decides to retry.
However, we weren't waiting for that cache-invalidation to go through - so there was the chance that an `/api/v2/user` request was still in-flight while we were redirecting after a successful login. If the request made it back prior to the redirect - login would work on the first try. If the request took longer - SWR would serve the stale, erroneous user from the cache.
Luckily the fix is simple - `mutate` in the SWR API returns a promise, so we can just wait for that to go through before redirecting. Unfortunately, though, this is tricky to exercise in a unit test because with the SWR model, the login logic is spread between `_app.tsx`, `UserContext.tsx`, and `SignInForm.tsx`, and the race condition involves an integration of all of those places.
I found that there is a lint rule that can help protect us from making this mistake - [`typescript-eslint/no-floating-promises`](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/no-floating-promises.md) (it's a lint rule we wanted to turn on in `coder/m`, too, actually - just a lot of work to clean up the code for it!), so I turned it on as part of this PR, and it caught a couple extra places to check.
This just implements a basic sign-in flow, using the new endpoints in #29 :
This brings over several dependencies that are necessary:
- `formik`
- `yep`
Ports over some v1 code to bootstrap it:
- `FormTextField`
- `PasswordField`
- `CoderIcon`
And implements basic sign-in:
Fixes#37Fixes#43
This does not implement it navbar integration (importantly - there is no way to sign out yet, unless you manually delete your `session_token`). I'll do that in the next PR - figured this was big enough to get reviewed.
While starting on the create workspace flow - I noticed some weird CSS issues.
In particular, intermittently, the web UI would render like this:
...and when that happened, there'd be an accompanying error in the console:
The issue is that NextJS is trying to render the page on the server and use the styles - and sometimes the classnames mismatch between server-side and client-side rendering. We actually worked around this in `cdr/m` with a `<SafeHydration />` component and a custom `_document.tsx`
This change ports over both the component and custom `_document.tsx`. I noticed, in addition, I missed the favicons when switching to NextJS, so I brought those over too.
This change bundles the static assets like we have for v1 - using the [`embed`](https://pkg.go.dev/embed) go package. Fixes#22
In addition, it sets up a development script that runs `coderd` locally and serves the front-end, with hot-reloading. The script used is `./develop.sh`:
> NOTE: The UI is still placeholder, of course. Need to start testing out a simple, placeholder flow for the new v2 world as a next step
Summary of changes:
- Add build steps for `go` in the `Makefile`
- Add a step for production build, in which we use the `embed` tag
- Add a step for development, which doesn't need the `embed` tag - so we don't need to build the front-end twice
- Add `next export` build step to output front-end artifacts in `out`
- Add a `site` package for `go`
- Add `embed_static.go` and `embed.go`. This is mostly brought in as-is from v1, except removing some intercom/sentry CSP entries that we aren't using.
- Add a [next development server](https://nextjs.org/docs/advanced-features/custom-server)
- Add a `v2-dev` script, that runs `coderd` and the `next` dev server side-by-side
- Use the `site` package as the fallback handler.
- Add `.gitignore` entries for additional build collateral
This implements an initial GitHub Actions workflow for us - to be run on PRs and on `main` commits.
This just implements a really simple `style/fmt` check - running `prettier` on the `README.md`.
I assumed we'll stick with using a top-level `Makefile` for commands like in `m` and `link` - but open to alternatives, too!
Since I was adding a `package.json` and `node_modules` for this, I realized we were missing `.gitignore`s, so I added some a subset of the ignore files from `coder/m`
