- update some config settings to support "absolute"-style imports by
using a `#/` prefix
- migrate some of the imports in the `WorkspacesPage` to use the new
import style as a proof of concept
because of the change in import sorting behavior this results in, this
diff is already kind of hard to look at–even just from a small migration
for a single page. I think breaking this up into bite size pieces isn't
gonna be worth the work, and leaves more time for merge conflicts to
accrue, more times people would likely have to resolve them.
so I think as far as process for this, I'd like to...
- merge this PR as is, where the config changes are relatively easy to
spot in the haystack, with just enough imports updated to prove that the
config changes are correct
- merge another mega PR after this one which just bites the bullet and
migrates everything else in one fell swoop. it'll probably result in a
ton of merge conflicts for open PRs, but at least it'll only do so once
and then it can be over with.
resolvescoder/internal#205
The goal is to create a new page located in deployment settings to allow
users to create and update organization IDP sync settings.
- [x] Use shadcn button for export policy button
- [x] Disable save button if form is not dirty
- [x] Disable "Add IdP organization" button if idp org name or coder
orgs are empty
- [x] Add footnote label below organization sync field input
- [x] Add button to Delete rows in mapping table
- [x] Create Multi-select combox box component to select coder org to
map to idp org
- [x] Storybook tests
- [x] Tooltip for assign default org switch
- [x] Display success/error toast on form submission
<img width="1181" alt="Screenshot 2024-12-02 at 20 33 07"
src="https://github.com/user-attachments/assets/86877d3b-82ec-4ed2-b239-bf8497352a9e">
Summary:
This commit is a bit of a shotgun fix for various project settings.
Realistically, they could've been separate commits, but this is
convenience for just getting things into a green state to unblock
further work.
Details:
- Use our version of TS in vscode plugins
- organize vscode/settings.json
- fix tsconfig.test and tsconfig.prod (removes errors in test files)
- only use prod tsconfig in webpack
- point .eslintrc to both test and prod configs
- cleanup storybook
- running eslint in my workspace was OOMing. I configured
maxWorkers like we had in v1 to fix this.
- remove .storybook from code coverage
- remove .js files from code coverage --> after moving away
from Next.js, we don't allowJS in our tsconfig anymore. We only
use JS for configurations, it's not allowed in src code!
* refactor(site): match v1 tsconfig
Summary of changes:
* ordered configurations for ease of readability
* allowJs removed -> not needed after Next.js
* noImplicitAny removed -> this is set to true by strict
* strictNullChecks removed -> this is set to true by strict
* removed lingering next-env.d.ts in include
* refactor(site): simplify tsconfig.test.json
Because that the base tsconfig was simplified when changing from
Next.js, this one now duplicates most of it. I still believe having a
separate tsconfig is a good idea for the purposes of separating tests
from source code. It especially can make it easier for eslint and jest
performance.
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 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
Kayla はな
