docs: fix links (#37)

* doc: fixing github doc links

* fix: add rehype plugin to fix website links

* fix: update rehype md extension handler pattern

* doc: update link

Author: Romulad

docs/api.md

@@ -96,7 +96,7 @@ The most important feature of render is that the queries from
 [CLI Testing Library](https://github.com/crutchcorn/cli-testing-library) are
 automatically returned with their first argument bound to the testInstance.
 
-See [Queries](./queries) to learn more about how to use these queries and the
+See [Queries](./queries.md) to learn more about how to use these queries and the
 philosophy behind them.
 
 ### ByText
@@ -122,7 +122,7 @@ Queries for test instance `stdout` results with the given text (and it also
 accepts a TextMatch).
 
 These options are all standard for text matching. To learn more, see our
-[Queries page](./queries).
+[Queries page](./queries.md).
 
 ## `userEvent[eventName]`
 
@@ -132,11 +132,11 @@ userEvent[eventName](...eventProps)
 
 > While `userEvent` isn't usually returned on `render` in, say,
 > `React Testing Library`, we're able to do so because of our differences in
-> implementation with upstream. See our [Differences](./differences) doc for
+> implementation with upstream. See our [Differences](./differences.md) doc for
 > more.
 
 This object is the same as described with
-[`userEvent` documentation](./user-event) with the key difference that
+[`userEvent` documentation](./user-event.md) with the key difference that
 `instance` is not expected to be passed when bound to `render`.
 
 ## `debug`
@@ -158,7 +158,7 @@ debug()
 ```
 
 This is a simple wrapper around `prettyCLI` which is also exposed and comes from
-[CLI Testing Library](./debug).
+[CLI Testing Library](./debug.md).
 
 ## `hasExit`
 
@@ -184,7 +184,7 @@ so you can call `process.pid` etc. to inspect the process.
 ## `stdoutArr`/`stderrArr`
 
 Each of these is an array of what's output by their respective `std`\* pipe.
-This is used internally to create the [`debug`methods](./debug) and more.
+This is used internally to create the [`debug`methods](./debug.md) and more.
 They're defined as:
 
 ```typescript

docs/configure.md

@@ -25,7 +25,7 @@ to `waitFor`.
 
 ### `throwSuggestions` (experimental)
 
-When enabled, if [better queries](./queries) are available the test will fail
+When enabled, if [better queries](./queries.md) are available the test will fail
 and provide a suggested query to use instead. Default to `false`.
 
 To disable a suggestion for a single query just add `{suggest:false}` as an
@@ -51,7 +51,7 @@ to 1000ms.
 By default, we wait for the CLI to `spawn` the command from `render`. If we
 immediately resolve the promise to allow users to query, however, we lose the
 ability to `getByText` immediately after rendering. This
-[differs greatly from upstream Testing Library](./differences) and makes for
+[differs greatly from upstream Testing Library](./differences.md) and makes for
 a poor testing experience.
 
 As a result, we wait this duration before resolving the promise after the

docs/fire-event.md

@@ -5,7 +5,7 @@ title: "Firing Events"
 > **Note**
 >
 > Most projects have a few use cases for `fireEvent`, but the majority of the
-> time you should probably use [`userEvent`](./user-event).
+> time you should probably use [`userEvent`](./user-event.md).
 
 ## `fireEvent`
 
@@ -26,5 +26,5 @@ fireEvent[eventName](instance: TestInstance, eventProperties?: Object)
 ```
 
 Convenience methods for firing CLI events. Check out
-[src/event-map.js](../src/event-map.ts) for a full list as well as default
+[src/event-map.js](../packages/cli-testing-library/src/event-map.ts) for a full list as well as default
 `eventProperties`.

docs/introduction.md

@@ -51,11 +51,11 @@ will work when a real user uses it.
 
 # Further Reading
 
-- [API reference for `render` and friends](./api)
-- [Jest and Vitest matchers](./matchers)
-- [Mock user input](./user-event)
-- [Manually fire input events](./fire-event)
-- [Output matching queries](./queries)
-- [Debugging "CLI Testing Library" tests](./debug)
-- [Configure library options](./configure)
-- [Differences between us and other "Testing Library" projects](./differences)
+- [API reference for `render` and friends](./api.md)
+- [Jest and Vitest matchers](./matchers.md)
+- [Mock user input](./user-event.md)
+- [Manually fire input events](./fire-event.md)
+- [Output matching queries](./queries.md)
+- [Debugging "CLI Testing Library" tests](./debug.md)
+- [Configure library options](./configure.md)
+- [Differences between us and other "Testing Library" projects](./differences.md)

docs/queries.md

@@ -9,7 +9,7 @@ if no CLI instance is found or if it will return a Promise and retry. Depending
 on what app content you are selecting, different queries may be more or less
 appropriate.
 
-While our APIs [differ slightly](./differences) from upstream Testing
+While our APIs [differ slightly](./differences.md) from upstream Testing
 Library's,
 [their "About Queries" page summarizes the goals and intentions of this project's queries quite well](https://testing-library.com/docs/queries/about/).
 
@@ -176,7 +176,7 @@ getByText(
 ```
 
 This will search the instance to see if there's an `stdout` output matching the
-given [`TextMatch`](queries/about.mdx#textmatch).
+given [`TextMatch`](#textmatch).
 
 ```html
 Input your name:
@@ -211,7 +211,7 @@ getByText(
 ```
 
 This will search the instance to see if there's an `stderr` output matching the
-given [`TextMatch`](queries/about.mdx#textmatch).
+given [`TextMatch`](#textmatch).
 
 ```html
 Could not find file

docs/user-event.md

@@ -3,7 +3,7 @@ title: "User Event"
 ---
 
 [`user-event`][gh] is a helper that provides more advanced simulation of CLI
-interactions than the [`fireEvent`](./fire-event) method.
+interactions than the [`fireEvent`](./fire-event.md) method.
 
 ## Import
 
@@ -66,7 +66,7 @@ Keystrokes can be described:
   userEvent.keyboard('a[[') // translates to: a, [
   ```
 
-- Per [special key mapping](../src/user-event/keyboard/keyMap.ts) with the `[`
+- Per [special key mapping](../packages/cli-testing-library/src/user-event/keyboard/keyMap.ts) with the `[`
   symbol
 
   ```js
@@ -77,7 +77,7 @@ Keystrokes can be described:
   `f`.
 
 The mapping of special character strings are performed by a
-[default key map](../src/user-event/keyboard/keyMap.ts) portraying a "default"
+[default key map](../packages/cli-testing-library/src/user-event/keyboard/keyMap.ts) portraying a "default"
 US-keyboard. You can provide your own local keyboard mapping per option.
 
 ```js
@@ -106,6 +106,6 @@ mentioned previously. Here are some of the ones that are supported:
 | `[End]`        | End         |
 
 A full list of supported special characters that can be input can be found
-[in our key mapping file](../src/user-event/keyboard/keyMap.ts).
+[in our key mapping file](../packages/cli-testing-library/src/user-event/keyboard/keyMap.ts).
 
 [gh]: https://github.com/testing-library/user-event

pnpm-lock.yaml

@@ -3,8 +3,13 @@ import { defineConfig } from "astro/config";
 import starlight from "@astrojs/starlight";
 import react from "@astrojs/react";
 
+import { rehypeHandleMdExtension } from "./rehype-plugin";
+
 // https://astro.build/config
 export default defineConfig({
+  markdown: {
+    rehypePlugins: [rehypeHandleMdExtension]
+  },
   integrations: [
     react(),
     starlight({

website/astro.config.mjs

@@ -16,7 +16,8 @@
     "astro": "^5.0.2",
     "react": "^19.0.0",
     "react-dom": "^19.0.0",
-    "sharp": "^0.33.5"
+    "sharp": "^0.33.5",
+    "unist-util-visit": "^5.0.0"
   },
   "devDependencies": {
     "@types/react": "^19.0.2",

website/package.json

@@ -0,0 +1,23 @@
+import { visit } from "unist-util-visit";
+
+export const rehypeHandleMdExtension = () => {
+    const pattern = /^(\..+)\.md(.*)/;
+
+    const canBeProcessed = (node) => (
+        node.tagName === "a" &&
+        node.properties.href &&
+        pattern.test(node.properties.href)
+    )
+
+    const processNode = (node) => {
+        const href = node.properties.href;
+        const results = href.match(pattern)
+        node.properties.href = `${results[1]}${results[2]}`;
+    }
+
+    return (tree) => {
+        visit(tree, "element", (node) => {
+            canBeProcessed(node) && processNode(node)
+        })
+    }
+}