mirror of
https://github.com/coder/coder.git
synced 2026-09-24 15:04:27 +08:00
Normalizes non-standard code-fence language tags across `docs/**` so a strict highlighter (Shiki, used by Fumadocs) won't fail the build on an unrecognized language, and unifies redundant synonym tags onto one canonical form per language. The current renderer (Speed-Highlight) detects the language from the code content, not the fence label, so this drift wasn't visible until now. ## Changes - `hcl` -> `tf` (199 fences, including indented ones nested in numbered/bulleted lists). Shiki ships `hcl` and `terraform` as two distinct grammars (not aliases); every `hcl`-tagged fence in `docs/**` is actually Terraform resource/data/provider syntax, so the more specific `terraform` grammar is correct for all of them. `tf` is Shiki's own alias for that grammar, and it's also what GitHub's own markdown renderer resolves to the same HCL/Terraform highlighting. - `pwsh`/`powershell` -> `ps1`. Both `ps` and `ps1` are registered PowerShell aliases in Shiki, but on GitHub's renderer only `.ps1` is a registered file extension (`.ps` isn't), so `ps1` renders identically to `powershell` there today while bare `ps` would silently lose highlighting. - `env` -> `dotenv` (a dedicated Shiki grammar for `KEY=VALUE` files) - `text`/`output`/`none`/`url` -> `txt`. Same built-in plain-text fallback either way, just shorter. - `Dockerfile` -> `dockerfile` (lowercase) - `bash`/`shell` -> `sh` (732 fences). Shiki and GitHub both alias all three to a single shell grammar; this was already the style guide's stated preference, just not enforced across the existing corpus until now. - `markdown` -> `md` (4 fences). Alias of the same grammar in both Shiki and GitHub. - `jsonc` -> `json` (1 fence). The block has no comments or trailing commas, so it doesn't need the comments-capable grammar. - `ts` -> `tsx` (2 fences, `docs/about/contributing/frontend.md`). Verified the actual content tokenizes identically under both grammars, and a sibling block in the same file already needs `tsx` for real JSX, so unifying to one tag is safe for this file. Documented a caveat: `tsx` mis-tokenizes the legacy angle-bracket type-assertion syntax (`<Type>value`), which is invalid in real `.tsx` files anyway, so use `value as Type` instead. - `yml` -> `yaml` (1 fence) - Updated `docs/.style/style-guide/formatting.md` to document all canonical tags `promql` (2 fences) and `caddyfile` (2 fences) are left as-is. Shiki doesn't bundle a grammar for either, so they need a custom grammar registration when the site adopts Shiki, rather than degrading to `txt`. Tracked as follow-up work under DOCS-118 and [DOCS-544](https://linear.app/codercom/issue/DOCS-544/vendor-a-local-promql-grammar-for-shiki-syntax-highlighting) (promql). Does not touch `offlinedocs/`. Linear: [DOCS-476](https://linear.app/codercom/issue/DOCS-476/normalize-docs-code-fence-languages-de-risk-shikifumadocs) <details> <summary>How the fence tags were verified</summary> Each tag was tested against a real `shiki@latest` highlighter instance (`codeToHtml`/`codeToTokens`) and cross-checked against GitHub's `@wooorm/starry-night` grammar sources (the renderer that actually displays these `.md` files today, in repo browsing and PR diffs), since that's what determines whether brevity is safe before Shiki adoption: ```text FAIL env -- Language `env` is not included in this bundle. FAIL Dockerfile -- Language `Dockerfile` is not included in this bundle. FAIL promql -- Language `promql` is not included in this bundle. FAIL caddyfile -- Language `caddyfile` is not included in this bundle. FAIL pwsh -- Language `pwsh` is not included in this bundle. FAIL output -- Language `output` is not included in this bundle. ``` `hcl` doesn't error in Shiki, since it's a real grammar, but that's exactly the trap: it was silently rendering every fence with the generic HCL grammar instead of the Terraform-specific one. Every `hcl`-tagged fence in `docs/**` was manually checked against `origin/main` and is genuinely Terraform content. For `ts`/`tsx`, tokenizing the actual doc content confirmed identical output under both grammars; a synthetic test with the legacy angle-bracket cast syntax confirmed `tsx` degrades on that specific construct, which the style guide now calls out. The first normalization pass only matched fence tags at column 0 (`^```tag$`), missing tags indented inside numbered/bulleted lists. A follow-up pass caught the remaining occurrences at any indentation level. </details> --- *This PR description and the underlying changes were prepared with Coder Agents assistance.*
88 lines
3.0 KiB
Markdown
88 lines
3.0 KiB
Markdown
# DX
|
||
|
||
[DX](https://getdx.com) is a developer intelligence platform used by engineering
|
||
leaders and platform engineers.
|
||
|
||
DX uses metadata attributes to assign information to individual users.
|
||
While it's common to segment users by `role`, `level`, or `geo`, it’s become increasingly
|
||
common to use DX attributes to better understand usage and adoption of tools.
|
||
|
||
You can create a `Coder` attribute in DX to segment and analyze the impact of Coder usage on a developer’s work, including:
|
||
|
||
- Understanding the needs of power users or low Coder usage across the org
|
||
- Correlate Coder usage with qualitative and quantitative engineering metrics,
|
||
such as PR throughput, deployment frequency, deep work, dev environment toil, and more.
|
||
- Personalize user experiences
|
||
|
||
## Requirements
|
||
|
||
- A DX subscription
|
||
- Access to Coder user data through the Coder CLI, Coder API, an IdP, or an existing Coder-DX integration
|
||
- Coordination with your DX Customer Success Manager
|
||
|
||
## Extract Your Coder User List
|
||
|
||
<div class="tabs">
|
||
|
||
You can use the Coder CLI, Coder API, or your Identity Provider (IdP) to extract your list of users.
|
||
|
||
If your organization already uses the Coder-DX integration, you can find a list of active Coder users directly within DX.
|
||
|
||
### CLI
|
||
|
||
Use `users list` to export the list of users to a CSV file:
|
||
|
||
```sh
|
||
coder users list > users.csv
|
||
```
|
||
|
||
Visit the [users list](../../reference/cli/users_list.md) documentation for more options.
|
||
|
||
### API
|
||
|
||
Use [get users](../../reference/api/users.md#get-users):
|
||
|
||
```sh
|
||
curl -X GET http://coder-server:8080/api/v2/users \
|
||
-H 'Accept: application/json' \
|
||
-H 'Coder-Session-Token: API_KEY'
|
||
```
|
||
|
||
To export the results to a CSV file, you can use the `jq` tool to process the JSON response:
|
||
|
||
```sh
|
||
curl -X GET http://coder-server:8080/api/v2/users \
|
||
-H 'Accept: application/json' \
|
||
-H 'Coder-Session-Token: API_KEY' | \
|
||
jq -r '.users | (map(keys) | add | unique) as $cols | $cols, (.[] | [.[$cols[]]] | @csv)' > users.csv
|
||
```
|
||
|
||
Visit the [get users](../../reference/api/users.md#get-users) documentation for more options.
|
||
|
||
### IdP
|
||
|
||
If your organization uses a centralized IdP to manage user accounts, you can extract user data directly from your IdP.
|
||
|
||
This is particularly useful if you need additional user attributes managed within your IdP.
|
||
|
||
</div>
|
||
|
||
## Contact your DX Customer Success Manager
|
||
|
||
Provide the file to your dedicated DX Customer Success Manager (CSM).
|
||
|
||
Your CSM will import the CSV of individuals using Coder, as well as usage frequency (if applicable) into DX to create a `Coder` attribute.
|
||
|
||
After the attribute is uploaded, you'll have a Coder filter option within your DX reports allowing you to:
|
||
|
||
- Perform cohort analysis (Coder user vs non-user)
|
||
- Understand unique behaviors and patterns across your Coder users
|
||
- Run a [study](https://getdx.com/studies/) or setup a [PlatformX](https://getdx.com/platformx/) event for deeper analysis
|
||
|
||
## Related Resources
|
||
|
||
- [DX Data Cloud Documentation](https://docs.getdx.com/)
|
||
- [Coder CLI](../../reference/cli/users.md)
|
||
- [Coder API](../../reference/api/users.md)
|
||
- [PlatformX Integration](./platformx.md)
|