monaco doesn't know that it needs to resize itself

it broke with the switch to monaco

At the moment the 'editor' is just a textarea. We need to replace this with a proper CodeMirror-powered editor. @pngwn has been exploring this

It might be nice to track people's progress (associated with a GitHub account?)

Once #54 is merged, it'd be good to show the webcontainer status (booting, installing, running dev etc)

--font-mono is set as --font-mono: Menlo, Monaco, 'Courier New', monospace; but the Menlo and Monaco fonts don't have their sources declared.

If the device doesn't have them installed it'll render Courier New, which is thinner and harder to read.

Related to #4

at present, old files stick around in the app

Some tutorial sections have dependencies on npm packages. Need to account for them somehow, ideally without making them dependencies of the site itself. It's only by 'accident' that the svelte imports work

Filing this under 'one day' — it would be great to use CodeMirror 6 instead of Monaco, since it works on mobile and is generally (I believe) more accessible. It would be a big lift though.

vm.fs.rm(file) fails:

would be neat if we could opt into TypeScript, both as .ts and lang="ts", and opt into JSDoc otherwise

I can't decide which of these is better from the point of view of someone figuring out what they're supposed to do:

Previously: #54 (comment)

We fetch modules so that we can reliably determine whether the user has completed a given exercise, but this fails with webcontainers (not sure why). If it's not possible to fetch them, we may need to revert to byte-for-byte comparisons or something else.

Not gonna lie, I have mostly no idea what is involved in this. But it would be cool if we could get red squigglies for code like this...

/** @type {number} */
const num = 'definitely not a number';
const doubled = num * 2;

...and if stuff in node_modules could get resolved by Monaco (including svelte, svelte/store etc, which currently resolve correctly, but only because the app itself has a dependency on them).

Also, can we get the editor to behave more like VSCode with the Svelte extension? At the moment it's just treating Svelte components as HTML files, which sorta works but isn't a viable long term solution.

The easy way to do this would be to put it in an afterNavigate function, but the correct way would be to add a way to attach arbitrary state to history entries

It's possible for the app to get into a broken state that it can't recover from. For example on 'Your first component', if you select 'world' and start typing curly braces...

<script>
	let name = 'Svelte';
</script>

<h1>Hello world!</h1>

...so that the component briefly looks like this...

<script>
	let name = 'Svelte';
</script>

<h1>Hello {world}!</h1>

...the fact that world is not defined will cause a ReferenceError that causes all subsequent updates to fail.

Honestly not sure how to recover from that, but it's important that we're able to.

The error overlay behaves a little strangely. If you introduce a syntax error then fix it, the error overlay isn't dismissed. If you add insignificant changes like whitespace, the overlay still isn't dismissed (@dominikg could this be related to this?). Eventually, if you add changes that are significant, the overlay goes away, but it feels like it should vanish as soon as the error is fixed.

When we add SvelteKit material, it'll become necessary to show the current pathname somehow. (I'm actually not sure if it's possible to track this from outside the iframe, but I'll be optimistic and assume that it is.)

We probably don't want this for the Svelte material.

Site needs a logo/title in the header

At the moment there's a single chapter of the OG tutorial in the content directory. We need to port the rest of the tutorial over, and add SvelteKit material.

We need to serve two audiences:

1. People who are new to Svelte altogether, who don't want to be distracted by SvelteKit-related stuff until it's time
2. People who already know Svelte, and want to skip ahead to SvelteKit stuff

It may be the case that the first group is best served by hiding the full project file structure, and zooming in on a single directory that contains the existing App.svelte (and whatever other files are relevant to the section).

It's also possible that we need a stricter separation between the Svelte sections and the SvelteKit sections, though I'm not 100% sure what that looks like.

in dev, vite can only use workers in browsers that support module workers. (in prod, they're bundled so it's not an issue.) we should show an error if you're using the wrong sort of browser in dev

from @dominikg:

Idea for ux: watch the editor content for code blocks/steps of the left hand side and turn the steps green once completed

from @benmccann

my main request would be a larger left panel by default. it looks like it defaults to about 1/4 of my screen on my laptop. I find it easier to consume if I give the left at least 1/3 of the screen

We'll likely need some help with this

I've closed about 10 PRs already from people who thought the tutorial is broken because they jumped right into it from Google or somewhere else / didn't read the preface.

Ideas:

• Rename "Show me" into "Show solution"
• Add a small banner above the code hinting at this when you enter the tutorial. It disappears once you type anything and doesn't reappear during the session

good point from @FractalHQ, we don't do a good job of connecting the different parts of the docs

Some sections need stuff like images, which don't currently work because everything is treated as text

On http://localhost:3000/tutorial/project-structure it's a bit funny to me that static is empty. Don't new SvelteKit projects have something in there?

The main tutorial is designed to be consumed in linear fashion, and we cover topics as concisely as possible. Something people often ask for is to have deeper dives on specific topics (auth in a SvelteKit app, how to use Svelte/Kit with particular libraries, etc), and this site might be a good format for doing that

Errors will be shown in the error overlay, but it's not the friendliest thing in the world (hard to know where the error is without sourcemaps/code frame). Warnings won't be shown at all.

Realistically this means doing analysis in a separate worker, which will be finicky

Currently there is a pnpm-lock and a package-lock, wondering if it's intentional?

At the moment we have to turbo install every time the page is opened. It's fast for what it's doing, but it's still totally wasteful — we can bundle up all the node_modules the tutorial apps need and serve them immutably, then write them directly to the filesystem. At that point there's really no need to install anything

Don't know all the specifics, but the app doesn't work on windows (it sort of works with WSL)

It's very easy to get lazy and just copy-paste code from the left hand side into the right hand side. This actively impedes learning, since you're not developing the muscle memory (for new syntax, etc) that comes from typing stuff by hand.

I think it would be valuable if, when trying to copy-paste from the <pre> elements on the left, the user was prompted to enable copy-paste for the remainder of the session, but encouraged not to. People might find it very annoying, but I think it's worth testing

incrementing the port is prone to failure

I've been bitten by this multiple times — we need to teach people how to allow third party cookies if stuff doesn't work (see also: #59)

At the moment, Vite logs are squelched. Ideally they'd be piped to the console somehow (websocket/SSEs). I don't think they need to be visible in the UI, but having them in devtools would be good

If the webcontainer doesn't start, we need to show an error of some sort

The code snippets in the <pre> elements should be syntax highlighted, ideally using identical logic to the editor (#3)

It's not terrible, but it's not great:

there's probably some stuff that should be in px rather than rem https://www.joshwcomeau.com/css/surprising-truth-about-pixels-and-accessibility/