[feat]: Move svelte.dev here (#8237)

* Push

* Remove `rootDir`

* Use tsconfig instead of jsconfig

* Push recent changes

* Better dark mode

* empty commit to try and trigger a deploy

* bump kit

* Fix site-kit dep

* Comment out blurb

* Update site-kit to 3.2.1

* Externalise sourcemap-codec

* Install sourcemap-codec as dep

---------

Co-authored-by: Rich Harris <[email protected]>

sites/svelte.dev/.env

@@ -0,0 +1,19 @@
+# for local development, copy this file to .env.local file and
+# fill in the blanks
+
+# server-side
+GITHUB_CLIENT_ID=
+GITHUB_CLIENT_SECRET=
+
+# Path to local copy of Svelte relative from sites/svelte.dev. Used by the REPL.
+# Optional. The default value assumes the svelte repo and sites repo are in the same directory.
+# LOCAL_SVELTE_PATH=../../../svelte
+
+# staging database
+SUPABASE_URL=https://kpaaohfbmxvespqoqdzp.supabase.co
+SUPABASE_KEY=
+
+PUBLIC_API_BASE="https://api.svelte.dev"
+
+# client-side
+VITE_MAPBOX_ACCESS_TOKEN=

sites/svelte.dev/.eslintrc.cjs

@@ -0,0 +1,54 @@
+module.exports = {
+	root: true,
+	rules: {
+		indent: [2, 'tab', { SwitchCase: 1 }],
+		semi: [2, 'always'],
+		'keyword-spacing': [2, { before: true, after: true }],
+		'space-before-blocks': [2, 'always'],
+		'no-mixed-spaces-and-tabs': [2, 'smart-tabs'],
+		'no-cond-assign': 0,
+		'no-unused-vars': 2,
+		'object-shorthand': [2, 'always'],
+		'no-const-assign': 2,
+		'no-class-assign': 2,
+		'no-this-before-super': 2,
+		'no-var': 2,
+		'no-unreachable': 2,
+		'valid-typeof': 2,
+		'quote-props': [2, 'as-needed'],
+		'one-var': [2, 'never'],
+		'prefer-arrow-callback': 2,
+		'prefer-const': [2, { destructuring: 'all' }],
+		'arrow-spacing': 2,
+		'no-inner-declarations': 0,
+		'require-atomic-updates': 0
+	},
+	env: {
+		es6: true,
+		browser: true,
+		node: true,
+		mocha: true
+	},
+	extends: ['eslint:recommended', 'plugin:import/errors', 'plugin:import/warnings'],
+	plugins: ['svelte3'],
+	overrides: [
+		{
+			files: ['*.svelte'],
+			processor: 'svelte3/svelte3'
+		}
+	],
+	parserOptions: {
+		ecmaVersion: 9,
+		sourceType: 'module'
+	},
+	settings: {
+		'import/core-modules': ['svelte'],
+		'svelte3/compiler': (() => {
+			try {
+				return require('svelte/compiler');
+			} catch (e) {
+				return null;
+			}
+		})()
+	}
+};

sites/svelte.dev/.gitignore

@@ -1,10 +1,11 @@
-.DS_Store
-node_modules
-/build
-/.svelte-kit
-/package
-.env
-.env.*
-!.env.example
-vite.config.js.timestamp-*
-vite.config.ts.timestamp-*
+/.env.local
+/.svelte-kit/
+/build/
+/functions/
+
+/static/svelte-app.json
+/scripts/svelte-app/
+/src/routes/_components/Supporters/contributors.jpg
+/src/routes/_components/Supporters/contributors.js
+/src/routes/_components/Supporters/donors.jpg
+/src/routes/_components/Supporters/donors.js

sites/svelte.dev/.prettierrc

@@ -1,9 +1,5 @@
 {
-	"useTabs": true,
 	"singleQuote": true,
-	"trailingComma": "none",
 	"printWidth": 100,
-	"plugins": ["prettier-plugin-svelte"],
-	"pluginSearchDirs": ["."],
-	"overrides": [{ "files": "*.svelte", "options": { "parser": "svelte" } }]
+	"useTabs": true
 }

sites/svelte.dev/README.md

@@ -1,38 +1,69 @@
-# create-svelte
+## Running locally
 
-Everything you need to build a Svelte project, powered by [`create-svelte`](https://github.com/sveltejs/kit/tree/master/packages/create-svelte).
+A local database is only required in dev mode if you want to test reading and writing saved REPLs on it. Without a local database in dev mode, the REPL will be able to load saved REPLs from the production database, but not save them.
 
-## Creating a project
+Note also that in dev mode, the REPL will currently only work in Chrome, [as noted in the Vite documentation](https://vitejs.dev/guide/features.html#web-workers), pending support in Firefox for `import` statements in web workers.
 
-If you're seeing this, you've probably already done this step. Congrats!
+If you do want to use a database, set it up on [Supabase](https://supabase.com) with the instructions [here](../../db) and set the corresponding environment variables.
 
-```bash
-# create a new project in the current directory
-npm create svelte@latest
+Run the site sub-project:
 
-# create a new project in my-app
-npm create svelte@latest my-app
+```bash
+pnpm install
+pnpm dev
 ```
 
-## Developing
+and navigate to [localhost:5173](http://localhost:5173).
 
-Once you've created a project and installed dependencies with `npm install` (or `pnpm install` or `yarn`), start a development server:
+The first time you run the site locally, it will update the list of Contributors and REPL dependencies. After this it won't run again unless you force it by running:
 
 ```bash
-npm run dev
-
-# or start the server and open the app in a new browser tab
-npm run dev -- --open
+pnpm update
 ```
 
-## Building
+## Running using the local copy of Svelte
+
+By default, the REPL will fetch the most recent version of Svelte from https://unpkg.com/svelte. When running the site locally, you can also use your local copy of Svelte.
 
-To create a production version of your app:
+To produce the proper browser-compatible UMD build of the compiler, you will need to run `npm run build` (or `npm run dev`) in the `svelte` repository with the `PUBLISH` environment variable set to any non-empty string:
 
 ```bash
-npm run build
+git clone https://github.com/sveltejs/svelte.git
+cd svelte
+npm ci
+PUBLISH=1 npm run build
 ```
 
-You can preview the production build with `npm run preview`.
+The default configuration assumes that the `sites` repository and the `svelte` repository are in the same directory. If not, you can set `LOCAL_SVELTE_PATH` in `sites/svelte.dev/.env` to a different path to the local copy of Svelte.
+
+Then visit the REPL at [localhost:5173/repl?version=local](http://localhost:5173/repl?version=local). Please note that the local REPL only works with `pnpm dev` and not when building the site for production usage.
+
+## REPL GitHub integration
+
+In order for the REPL's GitHub integration to work properly when running locally, you will need to:
+
+- [create a GitHub OAuth app](https://github.com/settings/developers):
+  - set `Authorization callback URL` to `http://localhost:5173/auth/callback`;
+  - set `Application name` as you like, and `Homepage URL` as `http://localhost:5173/`;
+  - create the app and take note of `Client ID` and `Client Secret`
+- in this directory, create an `.env.local` file (see `.env.example`) containing:
+  ```
+  GITHUB_CLIENT_ID=[your app's Client ID]
+  GITHUB_CLIENT_SECRET=[your app's Client Secret]
+  ```
+
+The GitHub app requires a specific callback URL, and so cannot be used with the preview deployment in the staging environment.
+
+## Building the site
+
+To build the website, run `pnpm build`. The output can be found in `build`.
+
+## Testing
+
+Tests can be run using `pnpm test`.
+
+## Translating the API docs
+
+Anchors are automatically generated using headings in the documentation and by default (for the english language) they are latinised to make sure the URL is always conforming to RFC3986.
 
-> To deploy your app, you may need to install an [adapter](https://kit.svelte.dev/docs/adapters) for your target environment.
+If we need to translate the API documentation to a language using unicode chars, we can setup this app to export the correct anchors by setting up `SLUG_PRESERVE_UNICODE` to `true` in `config.js`.

sites/svelte.dev/config.js

@@ -0,0 +1,2 @@
+export const SLUG_PRESERVE_UNICODE = false;
+export const SLUG_SEPARATOR = '_';

sites/svelte.dev/content/blog/2016-11-26-frameworks-without-the-framework.md

@@ -0,0 +1,55 @@
+---
+title: "Frameworks without the framework: why didn't we think of this sooner?"
+description: You can't write serious applications in vanilla JavaScript without hitting a complexity wall. But a compiler can do it for you.
+author: Rich Harris
+authorURL: https://twitter.com/Rich_Harris
+---
+
+> Wait, this new framework has a *runtime*? Ugh. Thanks, I'll pass.
+> **– front end developers in 2018**
+
+We're shipping too much code to our users. Like a lot of front end developers, I've been in denial about that fact, thinking that it was fine to serve 100kb of JavaScript on page load – just use [one less .jpg!](https://twitter.com/miketaylr/status/227056824275333120) – and that what *really* mattered was performance once your app was already interactive.
+
+But I was wrong. 100kb of .js isn't equivalent to 100kb of .jpg. It's not just the network time that'll kill your app's startup performance, but the time spent parsing and evaluating your script, during which time the browser becomes completely unresponsive. On mobile, those milliseconds rack up very quickly.
+
+If you're not convinced that this is a problem, follow [Alex Russell](https://twitter.com/slightlylate) on Twitter. Alex [hasn't been making many friends in the framework community lately](https://twitter.com/slightlylate/status/728355959022587905), but he's not wrong. But the proposed alternative to using frameworks like Angular, React and Ember – [Polymer](https://www.polymer-project.org/1.0/) – hasn't yet gained traction in the front end world, and it's certainly not for a lack of marketing.
+
+Perhaps we need to rethink the whole thing.
+
+
+## What problem do frameworks *really* solve?
+
+The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that's not really true. At best, frameworks *move the complexity around*, away from code that you had to write and into code you didn't.
+
+Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your *concepts*. Frameworks are primarily a tool for structuring your thoughts, not your code.
+
+Given that, what if the framework *didn't actually run in the browser*? What if, instead, it converted your application into pure vanilla JavaScript, just like Babel converts ES2016+ to ES5? You'd pay no upfront cost of shipping a hefty runtime, and your app would get seriously fast, because there'd be no layers of abstraction between your app and the browser.
+
+
+## Introducing Svelte
+
+Svelte is a new framework that does exactly that. You write your components using HTML, CSS and JavaScript (plus a few extra bits you can [learn in under 5 minutes](https://v2.svelte.dev/guide)), and during your build process Svelte compiles them into tiny standalone JavaScript modules. By statically analysing the component template, we can make sure that the browser does as little work as possible.
+
+The [Svelte implementation of TodoMVC](https://svelte-todomvc.surge.sh/) weighs 3.6kb zipped. For comparison, React plus ReactDOM *without any app code* weighs about 45kb zipped. It takes about 10x as long for the browser just to evaluate React as it does for Svelte to be up and running with an interactive TodoMVC.
+
+And once your app *is* up and running, according to [js-framework-benchmark](https://github.com/krausest/js-framework-benchmark) **Svelte is fast as heck**. It's faster than React. It's faster than Vue. It's faster than Angular, or Ember, or Ractive, or Preact, or Riot, or Mithril. It's competitive with Inferno, which is probably the fastest UI framework in the world, for now, because [Dominic Gannaway](https://twitter.com/trueadm) is a wizard. (Svelte is slower at removing elements. We're [working on it](https://github.com/sveltejs/svelte/issues/26).)
+
+It's basically as fast as vanilla JS, which makes sense because it *is* vanilla JS – just vanilla JS that you didn't have to write.
+
+
+## But that's not the important thing
+
+Well, it *is* important – performance matters a great deal. What's really exciting about this approach, though, is that we can finally solve some of the thorniest problems in web development.
+
+Consider interoperability. Want to `npm install cool-calendar-widget` and use it in your app? Previously, you could only do that if you were already using (a correct version of) the framework that the widget was designed for – if `cool-calendar-widget` was built in React and you're using Angular then, well, hard cheese. But if the widget author used Svelte, apps that use it can be built using whatever technology you like. (On the TODO list: a way to convert Svelte components into web components.)
+
+Or [code splitting](https://twitter.com/samccone/status/797528710085652480). It's a great idea (only load the code the user needs for the initial view, then get the rest later), but there's a problem – even if you only initially serve one React component instead of 100, *you still have to serve React itself*. With Svelte, code splitting can be much more effective, because the framework is embedded in the component, and the component is tiny.
+
+Finally, something I've wrestled with a great deal as an open source maintainer: your users always want *their* features prioritised, and underestimate the cost of those features to people who don't need them. A framework author must always balance the long-term health of the project with the desire to meet their users' needs. That's incredibly difficult, because it's hard to anticipate – much less articulate – the consequences of incremental bloat, and it takes serious soft skills to tell people (who may have been enthusiastically evangelising your tool up to that point) that their feature isn't important enough. But with an approach like Svelte's, many features can be added with absolutely no cost to people who don't use them, because the code that implements those features just doesn't get generated by the compiler if it's unnecessary.
+
+
+## We're just getting started
+
+Svelte is very new. There's a lot of work still left to do – creating build tool integrations, adding a server-side renderer, hot reloading, transitions, more documentation and examples, starter kits, and so on.
+
+But you can already build rich components with it, which is why we've gone straight to a stable 1.0.0 release. [Read the guide](https://v2.svelte.dev/guide), [try it out in the REPL](/repl), and head over to [GitHub](https://github.com/sveltejs/svelte) to help kickstart the next era of front end development.

sites/svelte.dev/content/blog/2017-08-07-the-easiest-way-to-get-started.md

@@ -0,0 +1,66 @@
+---
+title: The easiest way to get started with Svelte
+description: This'll only take a minute.
+author: Rich Harris
+authorURL: https://twitter.com/Rich_Harris
+---
+
+Svelte is a [new kind of framework](/blog/frameworks-without-the-framework). Rather than putting a `<script src='svelte.js'>` tag on the page, or bringing it into your app with `import` or `require`, Svelte is a compiler that works behind the scenes to turn your component files into beautifully optimised JavaScript.
+
+Because of that, getting started with it can be a little bit confusing at first. How, you might reasonably ask, do you make a Svelte app?
+
+
+## 1. Use the REPL
+
+The [Svelte REPL](/repl) (Read-Eval-Print Loop) is the easiest way to begin. This is an interactive environment that allows you to modify code and instantly see the result. 
+
+You can choose from a list of [examples](/examples/), click the [REPL](/repl) link, and then tweak them until they do what you want.
+
+<aside><p>You'll need to have <a href="https://nodejs.org/">Node.js</a> installed, and know how to use the terminal</p></aside>
+
+At some point, your app will outgrow the REPL. Click the **download** button to save a `svelte-app.zip` file to your computer and uncompress it.
+
+Open a terminal window and set the project up...
+
+```bash
+cd /path/to/svelte-app
+npm install
+```
+
+...then start up a development server:
+
+```bash
+npm run dev
+```
+
+This will serve your app on [localhost:8080](http://localhost:8080) and rebuild it with [Rollup](https://rollupjs.org) every time you make a change to the files in `svelte-app/src`.
+
+## 2. Use degit
+
+When you download from the REPL, you're getting a customised version of the [sveltejs/template](https://github.com/sveltejs/template) repo. You can skip messing around with zip files by using [degit](https://github.com/Rich-Harris/degit), a project scaffolding tool.
+
+In the terminal, you can instantly create a new project like so:
+
+```bash
+npx degit sveltejs/template my-svelte-project
+cd my-svelte-project
+# to use TypeScript run:
+# node scripts/setupTypeScript.js
+
+npm install
+npm run dev
+```
+
+This will create a new project in the `my-svelte-project` directory, install its dependencies, and start a server on http://localhost:8080.
+
+You can find more information about using TypeScript [here](/blog/svelte-and-typescript).
+
+Once you've tinkered a bit and understood how everything fits together, you can fork [sveltejs/template](https://github.com/sveltejs/template) and start doing this instead:
+
+```bash
+npx degit your-name/template my-new-project
+```
+
+And that's it! Do `npm run build` to create a production-ready version of your app, and check the project template's [README](https://github.com/sveltejs/template/blob/master/README.md) for instructions on how to easily deploy your app to the web with [Vercel](https://vercel.com) or [Surge](http://surge.sh/).
+
+You're not restricted to using Rollup — there are also integrations for [webpack](https://github.com/sveltejs/svelte-loader), [Browserify](https://github.com/tehshrike/sveltify) and others, or you can use the [Svelte CLI](https://github.com/sveltejs/svelte-cli) (Update from 2019: with Svelte 3 the CLI was deprecated and we now use [sirv-cli](https://www.npmjs.com/package/sirv-cli) in our template. Feel free to use whatever tool you like!) or the [API](https://github.com/sveltejs/svelte/tree/v2#api) directly. If you make a project template using one of these tools, please share it with the [Svelte Discord chatroom](https://svelte.dev/chat), or via [@sveltejs](https://twitter.com/sveltejs) on Twitter!