feat(site-2): New Markdown renderer, FAQ, Blog, Tutorial, Docs, (#8603)

* New FAQ, new renderer

* Push blog stuff

* Fix blog posts

* Add tutorial to be rendered

* Update documentation/content/blog/2023-03-09-zero-config-type-safety.md

Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>

* Update documentation/content/blog/2023-03-09-zero-config-type-safety.md

Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>

* Revamp a lot of renderer, make it (soft) compatible with sveltekit

* Remove markdown types

* Clean up faq +page

* Document stuff

* Make the options more explicity

* chore(site-2): Restructure docs pt 2 (#8604)

* Push

* Update readme

* Push

* inor accessibility fix

* minr stuff

* Add prepare

* Run prettier

* Remove test script

* pnpm update

* Update sites/svelte.dev/src/routes/examples/[slug]/+page.svelte

Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>

* Update sites/svelte.dev/package.json

Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>

---------

Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>

---------

Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>

documentation/blog/2018-04-18-version-2.md

@@ -48,7 +48,8 @@ To see the full set of changes, consult the [svelte-upgrade README](https://gith
 
 Another thing that people often found confusing about Svelte is the way computed properties work. To recap, if you had a component with this...
 
-```js
+```ts
+// @noErrors
 export default {
 	computed: {
 		d: (a, b, c) => (a = b + c)
@@ -60,7 +61,8 @@ export default {
 
 In v2, we use [destructuring](http://www.jstips.co/en/javascript/use-destructuring-in-function-parameters/) instead:
 
-```js
+```ts
+// @noErrors
 export default {
 	computed: {
 		d: ({ a, b, c }) => (a = b + c)
@@ -83,6 +85,7 @@ If you need to support IE11 and friends, you will need to use a transpiler like
 In addition to `oncreate` and `ondestroy`, Svelte v2 adds two more [lifecycle hooks](https://v2.svelte.dev/guide#lifecycle-hooks) for responding to state changes:
 
 ```js
+// @noErrors
 export default {
 	onstate({ changed, current, previous }) {
 		// this fires before oncreate, and
@@ -100,6 +103,7 @@ export default {
 You can also listen to those events programmatically:
 
 ```js
+// @noErrors
 component.on('state', ({ changed, current, previous }) => {
 	// ...
 });
@@ -110,6 +114,7 @@ component.on('state', ({ changed, current, previous }) => {
 With the new lifecycle hooks, we no longer need the `component.observe(...)` method:
 
 ```js
+// @noErrors
 // before
 export default {
 	oncreate() {
@@ -134,6 +139,7 @@ This shrinks the amount of code Svelte needs to generate, and gives you more fle
 However, if you prefer to use `component.observe(...)`, then you can install it from [svelte-extras](https://github.com/sveltejs/svelte-extras):
 
 ```js
+// @noErrors
 import { observe } from 'svelte-extras';
 
 export default {
@@ -148,6 +154,7 @@ export default {
 This method no longer takes an optional `key` argument — instead, it always returns the entire state object:
 
 ```js
+// @noErrors
 // before
 const foo = this.get('foo');
 const bar = this.get('bar');
@@ -181,6 +188,7 @@ That causes unexpected behaviour, and has been changed: if you need to pass a li
 In most cases you'll never need to deal with the compiler directly, so this shouldn't require any action on your part. It's worth noting anyway: the compiler API has changed. Instead of an object with a mish-mash of properties, the compiler now returns `js`, `css`, `ast` and `stats`:
 
 ```js
+// @noErrors
 const { js, css, ast, stats } = svelte.compile(source, options);
 ```
 

documentation/blog/2018-12-27-virtual-dom-is-pure-overhead.md

@@ -13,7 +13,8 @@ It's time to take a closer look.
 
 In many frameworks, you build an app by creating `render()` functions, like this simple [React](https://reactjs.org/) component:
 
-```js
+```ts
+// @noErrors
 function HelloMessage(props) {
 	return <div className="greeting">Hello {props.name}</div>;
 }
@@ -22,6 +23,7 @@ function HelloMessage(props) {
 You can do the same thing without JSX...
 
 ```js
+// @noErrors
 function HelloMessage(props) {
 	return React.createElement('div', { className: 'greeting' }, 'Hello ', props.name);
 }
@@ -43,6 +45,7 @@ Misunderstood claims about virtual DOM performance date back to the launch of Re
 But hang on a minute! The virtual DOM operations are _in addition to_ the eventual operations on the real DOM. The only way it could be faster is if we were comparing it to a less efficient framework (there were plenty to go around back in 2013!), or arguing against a straw man — that the alternative is to do something no-one actually does:
 
 ```js
+// @noErrors
 onEveryStateChange(() => {
 	document.body.innerHTML = renderMyApp();
 });
@@ -73,6 +76,7 @@ Most obviously, [diffing isn't free](https://twitter.com/pcwalton/status/1015694
 Of these three steps, only the third has value in this case, since — as is the case in the vast majority of updates — the basic structure of the app is unchanged. It would be much more efficient if we could skip straight to step 3:
 
 ```js
+// @noErrors
 if (changed.name) {
 	text.data = name;
 }
@@ -85,6 +89,7 @@ if (changed.name) {
 The diffing algorithms used by React and other virtual DOM frameworks are fast. Arguably, the greater overhead is in the components themselves. You wouldn't write code like this...
 
 ```js
+// @noErrors
 function StrawManComponent(props) {
 	const value = expensivelyCalculateValue(props.foo);
 
@@ -95,6 +100,7 @@ function StrawManComponent(props) {
 ...because you'd be carelessly recalculating `value` on every update, regardless of whether `props.foo` had changed. But it's extremely common to do unnecessary computation and allocation in ways that seem much more benign:
 
 ```js
+// @noErrors
 function MoreRealisticComponent(props) {
 	const [selected, setSelected] = useState(null);
 

documentation/blog/2019-04-20-write-less-code.md

@@ -48,6 +48,7 @@ Reducing the amount of code you have to write is an explicit goal of Svelte. To
 How would we build this in React? It would probably look something like this:
 
 ```js
+// @noErrors
 import React, { useState } from 'react';
 
 export default () => {
@@ -118,6 +119,7 @@ In Vue, your markup must be wrapped in a `<template>` element, which I'd argue i
 In React, we have to respond to input events ourselves:
 
 ```js
+// @noErrors
 function handleChangeA(event) {
 	setA(+event.target.value);
 }
@@ -142,6 +144,7 @@ function increment() {
 In React, we use the `useState` hook:
 
 ```js
+// @noErrors
 const [count, setCount] = useState(0);
 
 function increment() {

documentation/blog/2019-04-22-svelte-3-rethinking-reactivity.md

@@ -36,6 +36,7 @@ To make that possible we first needed to rethink the concept at the heart of mod
 In old Svelte, you would tell the computer that some state had changed by calling the `this.set` method:
 
 ```js
+// @errors: 7017
 const { count } = this.get();
 this.set({
 	count: count + 1
@@ -45,6 +46,7 @@ this.set({
 That would cause the component to _react_. Speaking of which, `this.set` is almost identical to the `this.setState` method used in classical (pre-hooks) React:
 
 ```js
+// @errors: 7017
 const { count } = this.state;
 this.setState({
 	count: count + 1
@@ -61,13 +63,20 @@ That all changed with the advent of [hooks](https://reactjs.org/docs/hooks-intro
 
 So we took a step back and asked ourselves what kind of API would work for us... and realised that the best API is no API at all. We can just _use the language_. Updating some `count` value — and all the things that depend on it — should be as simple as this:
 
-```js
+```ts
+let count: number = 10;
+// ---cut---
 count += 1;
 ```
 
 Since we're a compiler, we can do that by instrumenting assignments behind the scenes:
 
-```js
+```ts
+let count: number = 10;
+const $$invalidate = <T>(name: string, value: T) => {
+	return void 0;
+};
+// ---cut---
 count += 1;
 $$invalidate('count', count);
 ```

documentation/blog/2022-12-14-announcing-sveltekit-1.0.md

@@ -13,7 +13,7 @@ To get started, run `npm create svelte@latest`, and visit the [docs](https://kit
 <div class="max">
 <figure style="max-width: 960px; margin: 0 auto">
 <div style="height: 0; padding: 0 0 57.1% 0; position: relative; margin: 0 auto;">
-	<iframe style="position: absolute; width: 100%; height: 100%; left: 0; top: 0; margin: 0;" src="https://www.youtube.com/embed/N4BRVkQVoMc" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+	<iframe style="position: absolute; width: 100%; height: 100%; left: 0; top: 0; margin: 0;" src="https://www.youtube-nocookie.com/embed/N4BRVkQVoMc" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 </div>
 
 <figcaption>Svelte Radio Live: the Christmas special</figcaption>

documentation/blog/2023-03-09-zero-config-type-safety.md

@@ -22,6 +22,12 @@ Before we dive in, let's recap how type safety works in SvelteKit.
 In SvelteKit, you get the data for a page in a `load` function. You _could_ type the event by using `ServerLoadEvent` from `@sveltejs/kit`:
 
 ```ts
+const database = {
+	getPost(slug: string | undefined): Promise<string> {
+		return Promise.resolve('hello world');
+	}
+};
+// ---cut---
 // src/routes/blog/[slug]/+page.server.ts
 import type { ServerLoadEvent } from '@sveltejs/kit';
 
@@ -71,6 +77,7 @@ After we have loaded our data, we want to display it in our `+page.svelte`. The
 When running the dev server or the build, types are auto-generated. Thanks to the file-system based routing, SvelteKit is able to infer things like the correct parameters or parent data by traversing the route tree. The result is outputted into one `$types.d.ts` file for each route, which looks roughly like this:
 
 ```ts
+// @errors: 2344 2694 2307
 // $types.d.ts
 import type * as Kit from '@sveltejs/kit';