I noticed Svelte published some v5 pre-releases. Previously you could only try out Svelte Runes by using the online playground. Now you can run them locally.

Here's how. You'll need:

• Node.js.
• pnpm - Svelte uses it, but npm should work too.

Download one of the version 5 pre-releases from the Svelte releases page and extract it. Or you could just clone the repo to get the bleeding edge version.

Then move into the dir and do a pnpm install to install the dependencies.

Then run pnpm run build to compile everything.

^^^ You know what, scrap that, silly me, I just realised that they are actually publishing these pre-releases to npm. So you can simply link your svelte dev dependency to the latest pre-release version.

Well then. Instead of linking in package.json to the version we just compiled, we can just link to the one on npm.

Anyway, I'll press on regardless. It's up to you if you want to compile it locally or not.

Create a new Svelte project in a separate directory.

npm create vite@latest # Select svelte option

In package.json find the svelte dev dependency and change the version.

To use the npm version:

"svelte": "5.0.0-next.15"

Otherwise, link to your locally compiled version of Svelte:

"svelte": "file:../svelte/packages/svelte"

And then npm install all your node_modules.

In Svelte 5 there's a new way of mounting the app. So you'll have to edit main.ts to look a bit like this:

import "./app.css";
import App from "./App.svelte";
import { createRoot } from "svelte";

const target = document.getElementById("app");

if (!target) throw new Error("Failed to find #app");

const app = createRoot(App, { target });

export default app;

Then you can run npm run dev and you should see the app running.

Change Counter.svelte to use runes, and away you go.

<script lang="ts">
  let count: number = $state(0);

  const onclick = () => {
    count += 1;
  };
</script>

<button {onclick}>
  count is {count}
</button>

Have run writing your next Svelte app with runes!

So you wanna jump from one moving train to another for fun?

You could just do a fresh install. Or you could try this. Basically we're going to reinstall your base system, then restore all your old files over the top. This means you can avoid reinstalling all your old programs and settings etc.

After many failed attempts, this is what worked for me. Recording it here for future reference and in case it's useful for anyone else. (In my case I was going from f2fs to btrfs btw.)

The main issue is making sure you don't overwrite the new /etc/fstab with your old one, otherwise you'll end up with a system that won't boot because it will be looking for your old filesystems.

Here's what you do.

Make a full system backup with something like Rescuezilla for if when you screw up your system and need to restore it.

Make a backup on an external drive of all your files. I used Timeshift with the RSYNC option.

Reinstall Arch on your main drive, and choose the filesystem you want to switch to.

Make sure the new system boots.

Then we're going to boot into the System Rescue CD and mount the new system drive and the old Timeshift backup.

Use lsblk to get your device names and replace them in the code below eg. nvme0n1p2 and sda1.

cd /mnt
mkdir new old
mount -t btrfs /dev/nvme0n1p2 new/
mount -t f2fs /dev/sda1 old/

(Replace filesystems and drive names with your own.)

Make a backup of the new fstab file.

cp new/@/etc/fstab new/@/etc/fstab.bak

Now we're going to copy the old Timeshift backup files to the new system.

I did this one directory at a time, just to be sure, starting with /home, then rebooting, then repeating the process with /usr, /var, and /root and the others and finally /etc.

For example:

rsync -av old/timeshift/2021-11-27-000000/localhost/home/ /new/@home/
rsync -av old/timeshift/2021-11-27-000000/localhost/usr/ /new/@/usr/

Replace the directory names with your own. (btrfs is a bit strange as it uses @ to denote subvolumes.)

If I remember correctly, I think I had to use the --ignore-times option for the /etc directory. This forces files to be overwritten, even if they're older. There was a little guesswork involved in this process and I want to go back over it sometime.

In the end, you'll want to restore the fstab backup file.

cp new/@/etc/fstab.bak new/@/etc/fstab

Then reboot. And hopefully you now have a working system.

If not, restore from your Rescuezilla backup and try, try again.

Good luck!

UPDATE-2023-12-27

I tried the process again and didn't seem to need --ignore-times this time. Also because Arch maps the @log/ subvolume to /var/log I removed the contents of @/var/log/ after I rsynced it over.