fix more md links

markdown-pages/blog/archived/a-note-on-bucklescripts-future-commitments.mdx

@@ -10,11 +10,11 @@ description: |
 ---
 
 > **Update / August 13th 2020:**
-> BuckleScript is now called ReScript. More infos [here](../2020-08-10-bucklescript-is-rebranding.mdx)
+> BuckleScript is now called ReScript. More infos [here](../bucklescript-is-rebranding.mdx)
 
 ## A Statement for the Future
 
-Our [new ReScript syntax announcement](./2020-07-01-bucklescript-8-1-new-syntax.mdx) generated lots of good feedback, but also raised some concerns from community members whose use-cases still align with our goal, but sometimes extend outside of it, and who are worried about further commitments to the ecosystem in the face of new unknowns.
+Our [new ReScript syntax announcement](./bucklescript-8-1-new-syntax.mdx) generated lots of good feedback, but also raised some concerns from community members whose use-cases still align with our goal, but sometimes extend outside of it, and who are worried about further commitments to the ecosystem in the face of new unknowns.
 
 This post is dedicated to answer some common questions regarding trust, breakages, and future investment.
 

markdown-pages/blog/archived/bucklescript-8-1-new-syntax.mdx

@@ -8,7 +8,7 @@ description: |
 ---
 
 > **Update / August 13th 2020:**
-> BuckleScript is now called ReScript, more infos [here](/blog/bucklescript-is-rebranding).
+> BuckleScript is now called ReScript, more infos [here](../bucklescript-is-rebranding.mdx).
 
 ## What's new?
 

markdown-pages/blog/archived/bucklescript-release-1-4-2.mdx

@@ -23,7 +23,6 @@ There are quite lots of enhancements to the build system, we strongly recommend
 users to re-read the documentation ([old
 docs](http://bucklescript.github.io/bucklescript/Manual.html#_build_system_support)).
 
-2. [FFI add a new
-   feature](/docs/manual/bind-to-js-function#fixed-arguments)
+2. [FFI add a new feature](../../docs/manual/bind-to-js-function.mdx#fixed-arguments)
 3. [FFI can handle `bs.obj` and `bs.string`
    combination](https://github.com/bucklescript/bucklescript/issues/1072)

markdown-pages/blog/archived/bucklescript-release-1-5-0.mdx

@@ -15,7 +15,7 @@ Besides a number of minor bug fixes and perf improvement, most notable changes
   is also first class, this also makes Reason for the first time available to
   Windows users.
 - FFI added
-  [`bs.uncurry`](/docs/manual/function#curry--uncurry)
+  [`bs.uncurry`](../../docs/manual/function.mdx#curry--uncurry)
   which will automatically uncurry the callback so the user land API is clearer
 - Improve [object label
   translation](https://bucklescript.github.io/bucklescript/Manual.html#_object_label_translation_convention)

markdown-pages/blog/archived/bucklescript-release-1-7-0.mdx

@@ -87,11 +87,11 @@ release.
 ### Unicode string and interpolation support
 
 See [String
-interpolation](/docs/manual/interop-cheatsheet#string-unicode--interpolation)
+interpolation](../../docs/manual/interop-cheatsheet.mdx#string-unicode--interpolation)
 
 ### Catch exceptions raised on JS side
 
-See [Catch exception](/docs/manual/exception)
+See [Catch exception](../../docs/manual/exception.mdx)
 
 ### Mixed data source
 
@@ -110,7 +110,7 @@ schema](http://bucklescript.github.io/bucklescript/docson/#build-schema.json)
 
 ### `bs.as` accept json literal support
 
-This feature is mentioned in the [Functions / Fixed Arguments](/docs/manual/bind-to-js-function#fixed-arguments) section.
+This feature is mentioned in the [Functions / Fixed Arguments](../../docs/manual/bind-to-js-function.mdx#fixed-arguments) section.
 
 ### Bug fixes, performance improvement, and stress tests
 

markdown-pages/blog/archived/bucklescript-release-3-1-0.mdx

@@ -31,8 +31,7 @@ A picture's worth a thousand words:
   alt="debugger after"
 />
 
-Please see [Better Data Structures Printing (Debug
-Mode)](/docs/reason-compiler/latest/better-data-structures-printing-debug-mode) for usage.
+Please see for usage.
 
 ## Even Better `bs.deriving abstract`
 
@@ -41,7 +40,7 @@ of a `bs.deriving abstract` can now accept functions.
 
 ## Pipe First Improvement
 
-[Pipe First](/docs/manual/pipe) now supports piping into variant tags!
+[Pipe First](../../docs/manual/pipe.mdx) now supports piping into variant tags!
 
 ```reason
 let result = name |. preprocess |. Some

markdown-pages/blog/archived/bucklescript-release-5-0.mdx

@@ -16,7 +16,7 @@ release and refmt is synced up, a detailed list of changes is available
 Several new features are introduced in this release:
 
 - first class `bs.variadic` support, documented
-  [here](/blog/feature-preview-variadic)
+  [here](./feature-preview-variadic.mdx)
 
 - we prebuilt binaries for Windows, MacOS and Linux, this will help reduce your
   CI build time significantly. For exotic OSes, it will fall back to build from

markdown-pages/blog/archived/state-of-reasonml-org-2020-q2-pt1.mdx

@@ -65,7 +65,7 @@ We also focused a lot on early feedback from the community, so we regularly [pos
 
 The current [official BuckleScript's API docs](https://bucklescript.github.io/bucklescript/api/index_modules.html) aren't visually stunning, but they _are_ important for getting things done as a user. The docs are maintained within the BuckleScript repository, and there was no process to make sure the documentation site remained up to date with each BuckleScript release. It also presented a huge bottleneck for anyone hoping to contribute from the outside. So [Nik Graf](https://twitter.com/nikgraf) bit the bullet, did the massive amount of grunt work to extract all the available modules and function headers into hand curated markdown files, and organize them into easily-maintained documents from a technical writer's perspective.
 
-So we now have most of BuckleScript v7's [JS / Belt module](/docs/manual/api/belt) documented.
+So we now have most of BuckleScript v7's [JS / Belt module](https://rescript-lang.org/docs/manual/api/latest/belt) documented.
 
 We are now working on further automating the process for generating BuckleScript documentation by adding JSON export functionality to `odoc`. As soon as this is done, we will upstream our latest hand curated changes to the BuckleScript inline documentation and also give better guidance on contributing to the JS / Belt documentation in the source code as well.
 
@@ -79,7 +79,7 @@ Our goal is to have a properly curated, well structured and streamlined overview
   caption="First hand-sketches of the reasonml.org structure"
 />
 
-It didn't take long until we realized that we can't just keep the upstream version in its original form, so we started to make adaptations where it made sense. We also accepted new additions from the community, such as explanations about [function signatures on optional arguments](/docs/manual/function#signatures-and-type-annotations) in the Reason manual, or a new decorator overview in the BuckleScript section.
+It didn't take long until we realized that we can't just keep the upstream version in its original form, so we started to make adaptations where it made sense. We also accepted new additions from the community, such as explanations about [function signatures on optional arguments](../../docs/manual/function.mdx#signatures-and-type-annotations) in the Reason manual, or a new decorator overview in the BuckleScript section.
 
 That said, we do keep track of new changes on the upstream sources and cherry-pick changes if necessary. To make this process more transparent, we introduced a version table on our [startpage](/) to make it easier to see the latest cherry-pick commit for each resource (ReasonML, BuckleScript, etc.).
 
@@ -109,9 +109,9 @@ We'll go into more detail in our future posts. Stay tuned!
 
 This article is part of the "State of reasonml.org 2020-Q2" series, which will cover following topics (please stay tuned for the upcoming posts):
 
-**Part 2) [Higher Quality Docs](/blog/state-of-reasonml-org-2020-q2-pt2)**<br/>How we automate things to improve docs quality and how we make sure that PRs get merged.
+- [Part 2](./state-of-reasonml-org-2020-q2-pt2.mdx)
 
-**Part 3) [Future Tools for the Community](/blog/state-of-reasonml-org-2020-q2-pt3)**<br/>How we'll generate API docs with our new [doc-tools](https://github.com/reason-association/doc-tools) and how the new Playground will look like
+- [Part 3](./state-of-reasonml-org-2020-q2-pt3.mdx)
 
 **Part 4) It's all Opinions**<br/>We'll dive into our documentation philosophy, our vision of the Reason Platform and ideas on how to tackle the "Reason Native" documentation.
 

markdown-pages/blog/archived/state-of-reasonml-org-2020-q2-pt2.mdx

@@ -11,7 +11,7 @@ description: |
 
 ## Higher Quality Docs
 
-In our [previous blogpost](/blog/state-of-reasonml-org-2020-q2-pt1) we talked about the rationale and general concepts of the `reasonml.org` project. In this post we want to highlight how we make sure that our documentation is easy to manage and easy to refactor.
+> **Go to [Part 1](./state-of-reasonml-org-2020-q2-pt1.mdx)** if you haven't read it yet.r documentation is easy to manage and easy to refactor.
 
 ## Automatic Quality Assurance
 
@@ -152,12 +152,12 @@ Happy docs browsing!
 
 This article is part of the "State of reasonml.org 2020-Q2" series (please stay tuned for the upcoming posts):
 
-**Part 3) [Future Tools for the Community](/blog/state-of-reasonml-org-2020-q2-pt3):**
+**Part 3) [Future Tools for the Community](./state-of-reasonml-org-2020-q2-pt3.mdx):**
 How we'll generate API docs with our new [doc-tools](https://github.com/reason-association/doc-tools) and how the new Playground will look like
 
 **Part 4) It's all Opinions:**
 We'll dive into our documentation philosophy, our vision of the Reason Platform and ideas on how to tackle the "Reason Native" documentation.
 
 ## Previous Posts
 
-- **Part 1) [Introduction to reasonml.org](/blog/state-of-reasonml-org-2020-q2-pt1)**
+- **Part 1) [Introduction to reasonml.org](./state-of-reasonml-org-2020-q2-pt1.mdx)**

markdown-pages/blog/archived/state-of-reasonml-org-2020-q2-pt3.mdx

@@ -10,7 +10,7 @@ description: |
 
 ## Future Tools for the Community
 
-In [part 2](/blog/state-of-reasonml-org-2020-q2-pt2) of this blog series, we talked about the automation process for quality assurance within the documentation platform itself, and how we want to improve the collaboration process for our contributors.
+In [Part 2](./state-of-reasonml-org-2020-q2-pt2.mdx) we've talked about automated
 
 This article will cover some features and exciting ideas we have been working on for quite a while now. Even though these features are not fully implemented yet, we still think it's important to communicate the whole spectrum of the project.
 
@@ -73,5 +73,5 @@ We'll dive into our documentation philosophy, our vision of the Reason Platform
 
 ## Previous Posts
 
-- **Part 1) [Introduction to reasonml.org](/blog/state-of-reasonml-org-2020-q2-pt1)**
-- **Part 2) [Higher Quality Docs](/blog/state-of-reasonml-org-2020-q2-pt1)**
+- > **Go to [Part 1](./state-of-reasonml-org-2020-q2-pt1.mdx)** if you haven't read it yet.
+- **Part 2) [Higher Quality Docs](./state-of-reasonml-org-2020-q2-pt2.mdx)**

markdown-pages/blog/archived/state-of-reasonml-org-2020-q2-pt4.mdx

@@ -10,7 +10,7 @@ description: |
 
 ## It's all Opinions
 
-This is the final part of our "State of reasonml.org Q1-2020" series. In [part 3](./state-of-reasonml-org-2020-q2-pt3.mdx), we gave our readers some insights on advanced features we've been working on for `reasonml.org` and showed how our tools might help the community to build better documentation experiences themselves.
+This is the final part of our "State of reasonml.org Q1-2020" series. > **Go to [Part 3](./state-of-reasonml-org-2020-q2-pt3.mdx)** if you haven't read it yet.
 
 Apart from the general progress perspective of the `reasonml.org` project, we also want to give you some more context on how we envision the documentation landscape for the Reason language in the near future. It should give you a perspective on how we see things, and we hope it will kick off some constructive community discussions on where things should be heading.
 
@@ -93,6 +93,6 @@ Happy documentation browsing!
 
 ## Previous Posts
 
-- **Part 1) [Introduction to reasonml.org](/blog/state-of-reasonml-org-2020-q2-pt1)**
-- **Part 2) [Higher Quality Docs](/blog/state-of-reasonml-org-2020-q2-pt1)**
-- **Part 3) [Future Tools for the Community](/blog/state-of-reasonml-org-2020-q2-pt3)**
+- **Part 1) [Introduction to reasonml.org](./state-of-reasonml-org-2020-q2-pt1.mdx)**
+- **Part 2) [Higher Quality Docs](./state-of-reasonml-org-2020-q2-pt2.mdx)**
+- **Part 3) [Future Tools for the Community](./state-of-reasonml-org-2020-q2-pt3.mdx)**

markdown-pages/blog/bucklescript-is-rebranding.mdx

@@ -26,7 +26,7 @@ BuckleScript started with the idea that **JavaScript programmers deserved a grea
 - a fast & reliable toolchain much needed in front-end and Node development,
 - various JS interop features that spawned an ecosystem of well typed libraries,
 - a production-ready standard library,
-- [and recently](/blog/archived/bucklescript-8-1-new-syntax), a fresh syntax made by a major contributor of Reason's old syntax.
+- [and recently](./archived/bucklescript-8-1-new-syntax.mdx), a fresh syntax made by a major contributor of Reason's old syntax.
 
 These developments have attracted many people into our community. But one bigger challenge persisted: newcomers dropped out at the sheer amount of extra incongruent tools and learning overhead from having to understand OCaml concepts, Reason concepts, and BuckleScript's concepts. Take, for example, what's required to make a React app using BuckleScript:
 
@@ -72,7 +72,7 @@ No. The new syntax & tools sit alongside the existing code. We **won't** remove
 
 **What's the editor tooling story?**
 
-Much more streamlined now! See our [Editor Plugins](/docs/manual/editor-plugins.mdx) page.
+Much more streamlined now! See our [Editor Plugins](../docs/manual/editor-plugins.mdx) page.
 
 Reason-language-server will continue working as-is for existing usage. We as first party don't work on ocaml's language server.
 

markdown-pages/blog/enhanced-ergonomics-for-record-types.mdx

@@ -141,7 +141,7 @@ let name = nameFromB(a :> b)
 
 Notice how `a` now has more fields than `b`, but we can still coerce `a` to `b` because `b` has a subset of the fields of `a`.
 
-In combination with [optional record fields](/docs/manual/record#optional-record-fields), one may coerce a mandatory field of an `option` type to an optional field:
+In combination with [optional record fields](../docs/manual/record.mdx#optional-record-fields), one may coerce a mandatory field of an `option` type to an optional field:
 
 ```rescript
 type a = {

markdown-pages/blog/new-rescript-logo.mdx

@@ -56,7 +56,7 @@ We'd like to position ReScript to be a community of product-first developers who
 
 ## Next Steps
 
-In the next few weeks, we will gradually roll out our new brand identity across our official communication platforms. We'll also provide marketing material and assets on our [brand assets page](/brand) for our users.
+In the next few weeks, we will gradually roll out our new brand identity across our official communication platforms. We'll also provide marketing material and assets on our [brand assets page](https://rescript-lang.org/brand) for our users.
 
 We hope you enjoyed our new design article. In the future, we're hoping to interleave our technical releases with a few design and UX-oriented posts. Stay tuned!
 

markdown-pages/blog/reforging-build-system.mdx

@@ -122,7 +122,7 @@ The `.cmi` file is automatically generated for every module. It acts as a contra
 
 If you do not write an explicit interface file (`.resi`), the compiler infers the interface from everything you export in the `.res` file. If you do write a `.resi` file, that becomes the explicit interface instead.
 
-Here's a concrete example with an explicit [interface file](/docs/manual/v12.0.0/module#signatures):
+Here's a concrete example with an explicit [interface file](../docs/manual/module.mdx#signatures):
 
 ```rescript
 // Button.resi

markdown-pages/blog/release-10-1.mdx

@@ -51,7 +51,7 @@ let logUserDetails = async (userId: string) => {
 }
 ```
 
-Learn more about async/await support in [our documentation](../../docs/manual/async-await.mdx).
+Learn more about async/await support in [our documentation](../docs/manual/async-await.mdx).
 
 ## New `promise` builtin type and `Js.Promise2` module
 
@@ -82,7 +82,7 @@ ReScript 10.1 now ships with JSX v4. Here's what's new:
 - **Two new transformation modes**. JSX v4 comes with a `classic` mode (= `React.createElement`) and `automatic` mode (= `jsx-runtime` calls). The latter is the new default, moving forward with `rescript/[email protected]` and `React@18`.
 - **Allow mixing JSX configurations on the project and module level.** Gradually mix and match JSX transformations and modes without migrating any old code!
 - **Pass `prop` types** to `@react.component`. You can now fine tune `@react.component` with your specific prop type needs. Very useful for libraries and frameworks to define component interfaces.
-- **Less boilerplate when using `React.Context`**. Check out our [example](/docs/react/migrate-react#reactcontext) for comparison.
+Less boilerplate when using `React.Context`.
 - **Revisited props spread operator.** This will allow users to spread records in JSX without sacrificing their sanity. Note that this implementation has harder constraints than its JS counterpart. (requires `rescript/[email protected]` or higher)
 - **Better type inference of props.** Type inference when passing e.g. variants that are defined in the same module as the component is much improved. With the earlier JSX version, you'd often need to write code like this in order for the compiler to understand which variant you're passing: `<Button variant=Button.Primary text="Click" />`. With JSX v4, you won't need to tell the compiler where the variant you're passing is located: `<Button variant=Primary text="Click" />`.
 
@@ -281,7 +281,7 @@ export {
 
 ### How to migrate to JSX v4?
 
-We provide a full [migration guide](/docs/react/migrate-react) with all the details of an migration.
+We provide a full migration guide with all the details of an migration.
 
 Make sure to also check out the [rescript-react changelog](https://github.com/rescript-lang/rescript-react/blob/master/CHANGELOG) as well.