[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_247":248,"_249":250},"routes/_app.x.$handle.$name",{"_101":100,"_32":45,"_109":87,"_27":110,"_13":14,"_111":-5,"_11":112,"_113":114,"_115":116,"_117":118,"_119":120,"_20":-5,"_121":122,"_123":124,"_125":25,"_126":127,"_128":58,"_129":-5,"_130":-5,"_131":132},"routes/_app.x.$handle.$name.branch.$branch.version.$version.diff",{"_11":12,"_13":14,"_15":16,"_17":-5,"_18":-5},"project",{"_43":44,"_32":45,"_38":46,"_47":-5,"_48":25,"_49":50,"_51":50,"_52":-5,"_53":-5,"_18":54,"_55":56,"_57":58,"_59":-5,"_60":61,"_62":63,"_64":65,"_66":-5,"_67":-5,"_68":-5,"_69":-5,"_70":71,"_72":71,"_73":74,"_75":74,"_76":74,"_77":71,"_78":71,"_79":80,"_81":82,"_83":84,"_85":25},"version",17,"changes",[19],"aiChatInfo","userId",{"_20":21,"_22":23,"_24":25,"_26":25,"_27":28,"_29":28},"file",{"_30":31,"_32":33,"_34":20,"_35":37,"_38":39,"_40":14,"_41":42,"_24":25},"previous",{"_30":31,"_32":33,"_34":20,"_35":36},"deleted",false,"deletedHere","path","posts/001-makingVtCli.md","latestPath","fileId","847addd4-1b37-11f0-a750-569c3dd06744","name","001-makingVtCli.md","fileType","content","![Introducing Vt](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/example-watch.webm)\n\nIntroducing VT: the official command line tool to edit, manage, and begin val town projects right from your computer!\n\nVal town gives you a super fast, light, simple, and intuitive way to instantly create websites. But until now, this entire experience has been on a polished web platform. There's a lot of reasons to want to work on your Val Town projects locally. Maybe you want to work from the comfort of your favorite editor, whether that's vscode, with your favorite extensions, theme, and keybinds, or Neovim. Or you want to access powerful local devtools, which are increasingly AI powered ones like Claude Code or AI powered IDEs. Maybe you want to use `git`, or some other version control system out side of Val Town. Or maybe you just want to keep a back up of a Val Town project, or work offline. Now you can!\n\n# Finding the path\n\nThere's a lot of different paths we could take to engineer a local val town development experience.\n\n![Diagram from https://www.cs.cmu.edu/~./fp/courses/15213-s07/lectures/15-filesys/index.html](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/bcbdf72d-0875-4288-ab8c-3b06b1cace32.webp)\n\nOriginally, this project took the form of a fuse file system. Fuse is a Linux protocol that lets you implement arbitrary file systems in userspace. By implementing a fuse val town file system, all edits locally are instantly reflected on the val town website, and vice versa (if you update remotely, then if you try to save locally your editor will say something along the lines of \"more recent edits found, are you sure you want to write\"). Fuse is very powerful -- writes, reads, and all other file system syscalls can be handled with whatever response you want.\n\nThis project was `vtfs`, a project with the goal of exposing val town functionality through a file system. Originally it was a side project of mine, because \"can I write the code in neovim\" was the first question I asked myself when I first saw Val Town. I love the elegance of a file being a website, and thought it would be fun to be able to do a \"touch website.ts\" to create them, via the magic of fuse, and val town!\n\n[And so I built it](https://github.com/404wolf/valfs)! `valfs` was really cool: you'd run `vt mount [dir]` and you'd get a folder with all of your vals in it.\n\nVt was built written in `golang` with [`go-fuse`](https://github.com/hanwen/go-fuse), because, I didn't want to deal with C++ package management, and I wanted to try `go`.\n\n![](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/37c9a2a8-3f0a-4b52-a9c7-cf7c0cc0799b.webp)\n\nUnfortunately `vtfs` no longer works anymore and because of breaking API changes, and, while there was work in progress on `vtfs` to add support for val town projects, development has paused on the project in favor of `vt`.\n\nWe decided to rewrite it, mostly for compatability reasons. Linux offers native fuse support, but MacOS and Windows definitely do not. For Mac, there's a project called [MacFuse](https://macfuse.github.io/) that acts as a kernel extension to provide fuse support to Mac. However, it's not totally stable, and [Apple is deprecating kernel extensions](https://developer.apple.com/support/kernel-extensions/) and it may not be the best long term solution. There's a really cool project called [fuse-t](https://www.fuse-t.org/) that takes a different approach, where it implements the fuse protocol by forwarding fuse to NFS (network file system), a protocol that Macs do natively support.\n\nEven though it's a total rewrite, though, many design choices for `vt` came from `vtfs`.\n\n# Going Git\n\n`vt` is heavily inspired by both `git` and [gh](https://cli.github.com/), the github CLI. There's elements like `vt push` and pull that are very `git`ty, and things like `vt create` that act like `gh repo create`.\n\n![Gh browse](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/017b5db4-0379-4965-a94f-e9101a69b485.webp)\n\nOne handy `vt` command that we added is `vt browse`. `vt browse` opens up the current project in a web browser. As we work on improving hybrid workflows with the CLI and website, we will probably turn to `gh` to extend `vt browse`'s functionality.\n\n### The Meaning of `VT Pull` and `VT Push`\n\nUnlike `git`, where you have a `stage` and `commits`, `vt` only has a notion of `pushing` and `pulling`. This means that the local state could conflict in ways with the remote state that could result in changes that we can't reconsile: like, if you pull and you have newer changes locally, or If you push and there are newer changes in the remote.\n\n[We spent a while considering what pushing and pulling meant](https://github.com/val-town/vt/issues/45). The conclusion we came to:\n\n* `pushing` is a forceful procedure. When you push we ensure that the remote state matches the local state, and by the end of the push the remote state should match the local state with no changes to the local state. This might sound scary, but we do versioning for projects, so in the worst case you could revert to an earlier version on the website and pull.\n* `pulling` is a \"graceful\" procedure. When you pull, you may receive modifications, deletions, creations, or renames to local files. For all of these changes except creations, pulling warns the user that local changes will be lost, and you need to confirm to complete the pull. This is implemented internally by doing a \"dry\" pull and checking what changes would be made locally.\n\nThis means that the contract for push is \"push the local state to make sure the remote matches it\" and pull is \"get the remote state and make sure the local state matches it.\"\n\nSomething we get for free is `status`. `git status` looks at changes since the previous commit, but `vt status` is identical to `vt push --dry-run`, and shows you all the changes that would get pushed.\n\n### Beautiful Abstractions\n\nAs it turns out, many of the internal vt operations are able to easily piggyback off of one another. Like `vt push --dry-run` being the same as `vt status`, `vt pull` just does a `vt clone`, and then removes stuff that does not exist on the remote that still exists locally, or `vt checkout` is somewhat like `vt pull`-ing the branch you are trying to check out. These abstractions make testing and maintenance much easier.\n\n### Syncing\n\nOne idea that we had to solve this problem of \"the meaning of push and pull\" was to totally scrap both, and change the contract to \"sync to a consistent state.\" As it turns out, syncing really just redirects all the complexity, and is still quite complicated to implement.\n\nI spent a while designing an algorithm for syncing, where the primary \"building block\" of the algorithm was to \"walk\" through revisions and make changes to the local state incrementally. Syncing would start by pulling to incorporate all remote changes locally, and then push the remainder. It also would look at modification times to try to guess which update should be kept in the case of local/remote conflicts.\n\n```\nProcedure Sync:\n 1. Pull Updates from Remote\n - While current_version < latest_version:\n - Fetch the delta for current_version --> current_version + 1 \n\t from the remote.\n - Apply the delta:\n - New File:\n - If the file does not exist locally:\n - Create it.\n - Else:\n - Keep the newer one (compare btime or maybe mtime?).\n - Deleted File:\n - If the local mtime <= than the remote delete time:\n - Delete it locally.\n - Else:\n - Do nothing, keep the local file. We'll push it back later.\n - Modified File:\n - If modified locally:\n - Keep the newer modification.\n - Else:\n - Update the local file with the remote version.\n - Increment current_version.\n\n 2. Push Local Changes\n - For each file in the local vt directory:\n - If file.mtime > remote_file.updatedAt:\n - Upload the file.\n - If the file exists locally but not on the server:\n - Upload it.\n\n 3. Cleanup Remote Server, Fix Local State\n - For each file in the recursive vt server listing:\n - If it does not exist locally, delete it from the remote.\n - Update the local file's mtime to be the server's\n - Update version: current_version++ (should match remote_version++).\n```\n\nWorking on `vt`, I came across a lot of really cool abstractions\n\n## The Live Dev Experience\n\nOne of the most important use cases of `vt` is \"watch\" functionality. From the beginning, my plan for this was to implement \"git\" behavior first (pushing and pulling), and then just doing file system watching to add live syncing using [Deno.watchFs](https://docs.deno.com/api/deno/~/Deno.watchFs) to handle file system events.\n\n![](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/79892400-37e7-4ab3-a862-02b1ecb724ce.webp)\n\nOne particularly annoying challenge with `vt watch` was handling debouncing. Deno's standard library has an [async module](https://jsr.io/@std/async) that was super useful for implementing `vt watch`. `vt watch` works by doing a `push` initially, and then whenever local changes are made running another `vt push`. It sounds super simple!\n\nThe issue is that there's a lot of different things that could trigger a \"files were changed\" notification, and doing the push itself is one of them (the `.vt` folder has files internally that get updated on a push). Instead of working out the corner cases, I added a grace for post-pushing before we are able to detect file changes again.\n\nI also debounce the push. Initially, I did this so that if you are doing large amounts of file modifications we wait until you're done before starting the push, but it turns out this is more important because of how editors will create ephemeral temporary files during writes. Now, when you edit a file, the editor might create transient files, but as long as it gets rid of them within the debounce the final state that gets pushed is the one that does not include those temporary files.\n\n## Naming\n\n### Val Types\n\nOne of the initial concerns was how one could edit val metadata locally, if we are limited to the context of files.\n\n![](Screenshot%202025-04-16%20at%206.32.46%20PM.webp)\n\n`vtfs`'s approach to this was to pack all of the metadata for a val into the file corresponding to it. For Val Town projects, it's a bit more complex, because there's metadata specific to vals in the project, and metadata for the entire project itself too. We decided that, in general, changing val metadata and other uniquely val town attributes is something that we would leave to the website.\n\n`vtfs` would indicate the type of a given val locally as `foobar.H.tsx` (or, if verbose, `foobar.http.tsx`), which was a really nice pattern. If you wanted to change the type of a val, you could just rename it to `foobar.script.tsx`. This pattern, however, turns out not to work as well for projects because vals in projects generally are suffixed with `.tsx`, so you would end up with `foobar.http.tsx.tsx`, and it would get messy quickly -- and there were some issues with Vscode not liking `.script.tsx`.\n\nInstead of doing strict enforcement -- maintaining a 1:1 mapping of file extension to val type -- `vt` intuits the val type only on creation. If you create a `foobar.tsx`, `vt` sees `.tsx` and assumes it's a script. If you create `foobar_http.tsx` or `foobar.http.tsx`, `vt` sees `.tsx`, knows it's a val and not a file, and then guesses it's an `http` val. But it never will change it after the fact, so you can change `foobar.http.tsx` to be a script val on the website, and that's what it will continue to be going forward.\n\n## Renaming\n\nIt might seem simple at first, but if you think about it, detecting whether a file was renamed is actually really tricky. If we move `foo.ts` to `bar.ts` how do we know that it wasn't a `CREATE bar.ts` and `DELETE foo.ts`? Originally we didn't plan on adding rename detection support to `vt` because of all the complexity that comes with rename detection.\n\n![](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/blob_file_1744341763182_recording.gif)\n\nBut then we realized that, without rename detection, if you move a val with configuration -- like cron config, or custom endpoint HTTP vals, then doing the deletion/creation would cause you to lose all your config! And so, we added rename detection to `vt`.\n\nThe rename detection algorithm is a bit complicated -- it works by looking at all files that got deleted and that got created, and then considering a file as renamed if a created file is sufficiently similar to a file that got deleted. When iterating over created files to see if a deleted file is similar enough to one of them, we use some heuristics to filter out files that could not possibly be similar enough, like the file length. Then we compute the Levenshtein distance between a given deleted file and created file, and consider a given created file \"renamed\" if it is above some theshold similar to a deleted file, and if it is similar enough to multiple, then the one it is most similar to [as it turns out, Deno's standard library has a super efficient edit distance function](https://jsr.io/@std/text). Git does fancy [directory rename detection](https://git-scm.com/docs/directory-rename-detection/2.22.0), which is something that, at least for now, `vt` does not do.\n\nBecause rename detection is relatively expensive, it is internally implemented as an optional operation that doesn't always get used for every `vt` operation. For example, there isn't a lot of reason to do rename detection for `vt pull` -- it would really just be for reporting.\n\n## Blob Store\n\nFor `vtfs`, something I wanted to add early on was a way to \"mount\" your val town blob store so that you could view, edit, and organize your blobs. With fuse, there's a ton of flexibility on how to implement inodes. `go-fuse` provides a lot of nice abstractions. For totally static files like `deno.json` I was using the [MemRegularFile](https://github.com/hanwen/go-fuse/blob/v2.7.2/fs/mem.go#L17) helper, which makes it trivial to create an Inode with static text contents. For Vals, I was doing it more manually, implementing the read and write methods for a custom `ValFile` Inode myself. But for blobs, I wanted to handle reads and writes by streaming the relavent portions of the file.\n\nWhen implementing my own write callback for fuse, I would be handling requests to write data to a region of a file (like, write 0001010101 starting at index 22 bytes). Our `/v1/blob` endpoint is somewhat restrictive here. You can only write an entire file, or get an entire file. Handling this was really tricky -- I could start a new upload to upload the entire state of the file, with the new change made in the current write call, but if you're writing a lot of data to a file (like if you `cp bigFile.png` to the folder that I was using to represent your val town blobs), then there would typically be a burst of write requests to write to consecutive regions of the file.\n\nI spent a long time working on setting up a pipe where I would handle consecutive writes, writes that start at index i, end at index i+k, and then a new write that starts at index i+k+1, etc, as a special case. Eventually, I got something working!\n\nFor `vtfs` I was using [Openapi Generator](https://github.com/OpenAPITools/openapi-generator), and it turned out that Val Town's OpenAPI specification didn't accept file sizes on the order of my tests -- where the response would include the file size, it was an integer, not a `format: int64` (long).\n\n![Working piped blob uploads](Pasted%20image%2020250414162037.webp)\n\nMaintaining this, and getting writes to work non consecutively continued to prove a huge challenge. `valfs` blob read/write support was a fun challenge to work on, but was never totally reliable.\n\n","![Introducing Vt](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/example-watch.webm)\n\nIntroducing VT: the official command line tool to edit, manage, and begin val\ntown projects right from your computer!\n\nVal town gives you a super fast, light, simple, and intuitive way to instantly\ncreate websites. But until now, this entire experience has been on a polished\nweb platform. There's a lot of reasons to want to work on your Val Town projects\nlocally. Maybe you want to work from the comfort of your favorite editor,\nwhether that's vscode, with your favorite extensions, theme, and keybinds, or\nNeovim. Or you want to access powerful local devtools, which are increasingly AI\npowered ones like Claude Code or AI powered IDEs. Maybe you want to use `git`,\nor some other version control system out side of Val Town. Or maybe you just\nwant to keep a back up of a Val Town project, or work offline. Now you can!\n\n# Finding the path\n\nThere's a lot of different paths we could take to engineer a local val town\ndevelopment experience.\n\n![Diagram from https://www.cs.cmu.edu/~./fp/courses/15213-s07/lectures/15-filesys/index.html](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/bcbdf72d-0875-4288-ab8c-3b06b1cace32.webp)\n\nOriginally, this project took the form of a fuse file system. Fuse is a Linux\nprotocol that lets you implement arbitrary file systems in userspace. By\nimplementing a fuse val town file system, all edits locally are instantly\nreflected on the val town website, and vice versa (if you update remotely, then\nif you try to save locally your editor will say something along the lines of\n\"more recent edits found, are you sure you want to write\"). Fuse is very\npowerful -- writes, reads, and all other file system syscalls can be handled\nwith whatever response you want.\n\nThis project was `vtfs`, a project with the goal of exposing val town\nfunctionality through a file system. Originally it was a side project of mine,\nbecause \"can I write the code in neovim\" was the first question I asked myself\nwhen I first saw Val Town. I love the elegance of a file being a website, and\nthought it would be fun to be able to do a \"touch website.ts\" to create them,\nvia the magic of fuse, and val town!\n\n[And so I built it](https://github.com/404wolf/valfs)! `valfs` was really cool:\nyou'd run `vt mount [dir]` and you'd get a folder with all of your vals in it.\n\nVt was built written in `golang` with\n[`go-fuse`](https://github.com/hanwen/go-fuse), because, I didn't want to deal\nwith C++ package management, and I wanted to try `go`.\n\n![](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/37c9a2a8-3f0a-4b52-a9c7-cf7c0cc0799b.webp)\n\nUnfortunately `vtfs` no longer works anymore and because of breaking API\nchanges, and, while there was work in progress on `vtfs` to add support for val\ntown projects, development has paused on the project in favor of `vt`.\n\nWe decided to rewrite it, mostly for compatability reasons. Linux offers native\nfuse support, but MacOS and Windows definitely do not. For Mac, there's a\nproject called [MacFuse](https://macfuse.github.io/) that acts as a kernel\nextension to provide fuse support to Mac. However, it's not totally stable, and\n[Apple is deprecating kernel extensions](https://developer.apple.com/support/kernel-extensions/)\nand it may not be the best long term solution. There's a really cool project\ncalled [fuse-t](https://www.fuse-t.org/) that takes a different approach, where\nit implements the fuse protocol by forwarding fuse to NFS (network file system),\na protocol that Macs do natively support.\n\nEven though it's a total rewrite, though, many design choices for `vt` came from\n`vtfs`.\n\n# Going Git\n\n`vt` is heavily inspired by both `git` and [gh](https://cli.github.com/), the\ngithub CLI. There's elements like `vt push` and pull that are very `git`ty, and\nthings like `vt create` that act like `gh repo create`.\n\n![Gh browse](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/017b5db4-0379-4965-a94f-e9101a69b485.webp)\n\nOne handy `vt` command that we added is `vt browse`. `vt browse` opens up the\ncurrent project in a web browser. As we work on improving hybrid workflows with\nthe CLI and website, we will probably turn to `gh` to extend `vt browse`'s\nfunctionality.\n\n### The Meaning of `VT Pull` and `VT Push`\n\nUnlike `git`, where you have a `stage` and `commits`, `vt` only has a notion of\n`pushing` and `pulling`. This means that the local state could conflict in ways\nwith the remote state that could result in changes that we can't reconsile:\nlike, if you pull and you have newer changes locally, or If you push and there\nare newer changes in the remote.\n\n[We spent a while considering what pushing and pulling meant](https://github.com/val-town/vt/issues/45).\nThe conclusion we came to:\n\n- `pushing` is a forceful procedure. When you push we ensure that the remote\n state matches the local state, and by the end of the push the remote state\n should match the local state with no changes to the local state. This might\n sound scary, but we do versioning for projects, so in the worst case you could\n revert to an earlier version on the website and pull.\n- `pulling` is a \"graceful\" procedure. When you pull, you may receive\n modifications, deletions, creations, or renames to local files. For all of\n these changes except creations, pulling warns the user that local changes will\n be lost, and you need to confirm to complete the pull. This is implemented\n internally by doing a \"dry\" pull and checking what changes would be made\n locally.\n\nThis means that the contract for push is \"push the local state to make sure the\nremote matches it\" and pull is \"get the remote state and make sure the local\nstate matches it.\"\n\nSomething we get for free is `status`. `git status` looks at changes since the\nprevious commit, but `vt status` is identical to `vt push --dry-run`, and shows\nyou all the changes that would get pushed.\n\n### Beautiful Abstractions\n\nAs it turns out, many of the internal vt operations are able to easily piggyback\noff of one another. Like `vt push --dry-run` being the same as `vt status`,\n`vt pull` just does a `vt clone`, and then removes stuff that does not exist on\nthe remote that still exists locally, or `vt checkout` is somewhat like\n`vt pull`-ing the branch you are trying to check out. These abstractions make\ntesting and maintenance much easier.\n\n### Syncing\n\nOne idea that we had to solve this problem of \"the meaning of push and pull\" was\nto totally scrap both, and change the contract to \"sync to a consistent state.\"\nAs it turns out, syncing really just redirects all the complexity, and is still\nquite complicated to implement.\n\nI spent a while designing an algorithm for syncing, where the primary \"building\nblock\" of the algorithm was to \"walk\" through revisions and make changes to the\nlocal state incrementally. Syncing would start by pulling to incorporate all\nremote changes locally, and then push the remainder. It also would look at\nmodification times to try to guess which update should be kept in the case of\nlocal/remote conflicts.\n\n```\nProcedure Sync:\n 1. Pull Updates from Remote\n - While current_version < latest_version:\n - Fetch the delta for current_version --> current_version + 1 \n\t from the remote.\n - Apply the delta:\n - New File:\n - If the file does not exist locally:\n - Create it.\n - Else:\n - Keep the newer one (compare btime or maybe mtime?).\n - Deleted File:\n - If the local mtime <= than the remote delete time:\n - Delete it locally.\n - Else:\n - Do nothing, keep the local file. We'll push it back later.\n - Modified File:\n - If modified locally:\n - Keep the newer modification.\n - Else:\n - Update the local file with the remote version.\n - Increment current_version.\n\n 2. Push Local Changes\n - For each file in the local vt directory:\n - If file.mtime > remote_file.updatedAt:\n - Upload the file.\n - If the file exists locally but not on the server:\n - Upload it.\n\n 3. Cleanup Remote Server, Fix Local State\n - For each file in the recursive vt server listing:\n - If it does not exist locally, delete it from the remote.\n - Update the local file's mtime to be the server's\n - Update version: current_version++ (should match remote_version++).\n```\n\nWorking on `vt`, I came across a lot of really cool abstractions\n\n## The Live Dev Experience\n\nOne of the most important use cases of `vt` is \"watch\" functionality. From the\nbeginning, my plan for this was to implement \"git\" behavior first (pushing and\npulling), and then just doing file system watching to add live syncing using\n[Deno.watchFs](https://docs.deno.com/api/deno/~/Deno.watchFs) to handle file\nsystem events.\n\n![](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/79892400-37e7-4ab3-a862-02b1ecb724ce.webp)\n\nOne particularly annoying challenge with `vt watch` was handling debouncing.\nDeno's standard library has an [async module](https://jsr.io/@std/async) that\nwas super useful for implementing `vt watch`. `vt watch` works by doing a `push`\ninitially, and then whenever local changes are made running another `vt push`.\nIt sounds super simple!\n\nThe issue is that there's a lot of different things that could trigger a \"files\nwere changed\" notification, and doing the push itself is one of them (the `.vt`\nfolder has files internally that get updated on a push). Instead of working out\nthe corner cases, I added a grace for post-pushing before we are able to detect\nfile changes again.\n\nI also debounce the push. Initially, I did this so that if you are doing large\namounts of file modifications we wait until you're done before starting the\npush, but it turns out this is more important because of how editors will create\nephemeral temporary files during writes. Now, when you edit a file, the editor\nmight create transient files, but as long as it gets rid of them within the\ndebounce the final state that gets pushed is the one that does not include those\ntemporary files.\n\n## Naming\n\n### Val Types\n\nOne of the initial concerns was how one could edit val metadata locally, if we\nare limited to the context of files.\n\n![](Screenshot%202025-04-16%20at%206.32.46%20PM.webp)\n\n`vtfs`'s approach to this was to pack all of the metadata for a val into the\nfile corresponding to it. For Val Town projects, it's a bit more complex,\nbecause there's metadata specific to vals in the project, and metadata for the\nentire project itself too. We decided that, in general, changing val metadata\nand other uniquely val town attributes is something that we would leave to the\nwebsite.\n\n`vtfs` would indicate the type of a given val locally as `foobar.H.tsx` (or, if\nverbose, `foobar.http.tsx`), which was a really nice pattern. If you wanted to\nchange the type of a val, you could just rename it to `foobar.script.tsx`. This\npattern, however, turns out not to work as well for projects because vals in\nprojects generally are suffixed with `.tsx`, so you would end up with\n`foobar.http.tsx.tsx`, and it would get messy quickly -- and there were some\nissues with Vscode not liking `.script.tsx`.\n\nInstead of doing strict enforcement -- maintaining a 1:1 mapping of file\nextension to val type -- `vt` intuits the val type only on creation. If you\ncreate a `foobar.tsx`, `vt` sees `.tsx` and assumes it's a script. If you create\n`foobar_http.tsx` or `foobar.http.tsx`, `vt` sees `.tsx`, knows it's a val and\nnot a file, and then guesses it's an `http` val. But it never will change it\nafter the fact, so you can change `foobar.http.tsx` to be a script val on the\nwebsite, and that's what it will continue to be going forward.\n\n## Renaming\n\nIt might seem simple at first, but if you think about it, detecting whether a\nfile was renamed is actually really tricky. If we move `foo.ts` to `bar.ts` how\ndo we know that it wasn't a `CREATE bar.ts` and `DELETE foo.ts`? Originally we\ndidn't plan on adding rename detection support to `vt` because of all the\ncomplexity that comes with rename detection.\n\n![](https://wolf-mermelstein-personal-website.s3.us-east-2.amazonaws.com/blob_file_1744341763182_recording.gif)\n\nBut then we realized that, without rename detection, if you move a val with\nconfiguration -- like cron config, or custom endpoint HTTP vals, then doing the\ndeletion/creation would cause you to lose all your config! And so, we added\nrename detection to `vt`.\n\nThe rename detection algorithm is a bit complicated -- it works by looking at\nall files that got deleted and that got created, and then considering a file as\nrenamed if a created file is sufficiently similar to a file that got deleted.\nWhen iterating over created files to see if a deleted file is similar enough to\none of them, we use some heuristics to filter out files that could not possibly\nbe similar enough, like the file length. Then we compute the Levenshtein\ndistance between a given deleted file and created file, and consider a given\ncreated file \"renamed\" if it is above some theshold similar to a deleted file,\nand if it is similar enough to multiple, then the one it is most similar to\n[as it turns out, Deno's standard library has a super efficient edit distance function](https://jsr.io/@std/text).\nGit does fancy\n[directory rename detection](https://git-scm.com/docs/directory-rename-detection/2.22.0),\nwhich is something that, at least for now, `vt` does not do.\n\nBecause rename detection is relatively expensive, it is internally implemented\nas an optional operation that doesn't always get used for every `vt` operation.\nFor example, there isn't a lot of reason to do rename detection for `vt pull` --\nit would really just be for reporting.\n\n## Blob Store\n\nFor `vtfs`, something I wanted to add early on was a way to \"mount\" your val\ntown blob store so that you could view, edit, and organize your blobs. With\nfuse, there's a ton of flexibility on how to implement inodes. `go-fuse`\nprovides a lot of nice abstractions. For totally static files like `deno.json` I\nwas using the\n[MemRegularFile](https://github.com/hanwen/go-fuse/blob/v2.7.2/fs/mem.go#L17)\nhelper, which makes it trivial to create an Inode with static text contents. For\nVals, I was doing it more manually, implementing the read and write methods for\na custom `ValFile` Inode myself. But for blobs, I wanted to handle reads and\nwrites by streaming the relavent portions of the file.\n\nWhen implementing my own write callback for fuse, I would be handling requests\nto write data to a region of a file (like, write 0001010101 starting at index 22\nbytes). Our `/v1/blob` endpoint is somewhat restrictive here. You can only write\nan entire file, or get an entire file. Handling this was really tricky -- I\ncould start a new upload to upload the entire state of the file, with the new\nchange made in the current write call, but if you're writing a lot of data to a\nfile (like if you `cp bigFile.png` to the folder that I was using to represent\nyour val town blobs), then there would typically be a burst of write requests to\nwrite to consecutive regions of the file.\n\nI spent a long time working on setting up a pipe where I would handle\nconsecutive writes, writes that start at index i, end at index i+k, and then a\nnew write that starts at index i+k+1, etc, as a special case. Eventually, I got\nsomething working!\n\nFor `vtfs` I was using\n[Openapi Generator](https://github.com/OpenAPITools/openapi-generator), and it\nturned out that Val Town's OpenAPI specification didn't accept file sizes on the\norder of my tests -- where the response would include the file size, it was an\ninteger, not a `format: int64` (long).\n\n![Working piped blob uploads](Pasted%20image%2020250414162037.webp)\n\nMaintaining this, and getting writes to work non consecutively continued to\nprove a huge challenge. `valfs` blob read/write support was a fun challenge to\nwork on, but was never totally reliable.\n","createdAt",["D",1744859095795],"branchVersion","branchId","52be303e-1b37-11f0-9141-569c3dd06744","id","52bb5288-1b37-11f0-9141-569c3dd06744","BlogTesting",["D",1744858487353],"deletedAt","legacyEnvVars","privacy","public","httpPrivacy","description","imageUrl","4555dd0e-707e-4444-acd3-049d206eb1db","pinnedFileId","381e52f7-5664-42c9-b102-6b157a5e4742","pinPreview",true,"pinMigrated","screenshotVersion",16,"likeCount",0,"orgId","bced381e-9ab2-4b55-929d-e7c5064f7f38","tursoName","tursoHostname","tursoMeasuredAt","pinned","userPerm","r","valPerm","blobPerm","rw","emailPerm","sqlitePerm","projectPerm","telemetryPerm","user",{"_101":100,"_108":104},"org",{"_101":100,"_102":-5,"_103":104,"_18":54,"_105":106,"_107":25},"branch",{"_13":86,"_32":87,"_43":42,"_88":44,"_89":90,"_91":92,"_93":50,"_94":95,"_96":97,"_98":45,"_99":100},"isOwned",23,"main","projectId","forkedBranchId","8e73c264-d835-11ef-bbbf-e6cdfca9ef9f","forkedBranchVersion",167,"forkedProjectPrivacy","forkedProjectId","8e7382ae-d835-11ef-bbbf-e6cdfca9ef9f","forkedProjectOrgId","e81e7335-6d4c-4764-a902-d0962bbfa9f7","projectName","userHandle","wolf","handle","displayName","avatar","https://img.clerk.com/eyJ0eXBlIjoicHJveHkiLCJzcmMiOiJodHRwczovL2ltYWdlcy5jbGVyay5kZXYvdXBsb2FkZWQvaW1nXzJvVXpPVUZRTjZGTGd2Q2t4c0RRdFpNZWJ5UCJ9","tier","pro","canRestrictVals","profileImageUrl","branchName","","adoptOrgId",{"_43":44,"_32":45,"_38":243,"_47":-5,"_48":25,"_49":50,"_51":50,"_52":-5,"_53":-5,"_18":54,"_55":56,"_57":58,"_59":-5,"_60":61,"_62":63,"_64":65,"_66":-5,"_67":-5,"_68":-5,"_69":-5,"_70":71,"_72":71,"_73":74,"_75":74,"_76":74,"_77":71,"_78":71,"_79":244,"_81":245,"_83":246,"_85":25},"tree",[204,206,208,209,210,211],"files",[204,205,206,207,208,209,210,211],"counts",{"_194":63,"_195":171,"_196":63,"_197":198,"_199":200},"contents",[144,145,146,147,148,149],"upstreamProject",{"_43":95,"_32":139,"_52":140,"_53":141,"_49":50,"_79":142},"upstreamBranch",{"_43":90,"_38":133,"_134":135,"_32":87,"_88":95,"_13":92,"_89":-5,"_91":-5,"_136":137,"_47":-5,"_85":25,"_49":50,"_99":138,"_64":97,"_98":139},"emptyEnvVars","flags",[],"hasHttpFiles","grants","orgs","customDomains",{},["D",1737491000655],"updatedAt",["D",1744030679667],"lockfileKey","1767103399424-esm.town_v_stevekrouse_markdownBlogStarter@167-main","stevekrouse","markdownBlogStarter","Starter template for a markdown blog","https://imagedelivery.net/iHX6Ovru0O7AjmyT5yZRoA/44a31e5c-3e8a-48a8-d067-5785c0b08200/square512?exp=1789684622&sig=70d44bb018a2464cbd9ebc1f9ca6119d0c09091ebc37b065fab87c7ec17a563f",{"_101":138,"_108":143},"https://images.clerk.dev/uploaded/img_2PqHa2Gsy93xQrjh2w78Xu0cChW.jpeg",{"_43":188,"_32":189,"_30":190,"_152":-5,"_41":42,"_40":191,"_153":58,"_38":192,"_13":63,"_34":186,"_35":-5,"_24":25,"_158":-5,"_27":193},{"_43":182,"_32":183,"_30":184,"_152":-5,"_41":42,"_40":171,"_153":58,"_38":185,"_13":63,"_34":186,"_35":-5,"_24":25,"_158":-5,"_27":187},{"_43":175,"_32":176,"_30":177,"_152":-5,"_41":42,"_40":178,"_153":58,"_38":179,"_13":63,"_34":20,"_35":180,"_24":25,"_158":-5,"_27":181},{"_43":166,"_32":167,"_30":168,"_152":-5,"_41":42,"_40":169,"_153":25,"_38":170,"_13":171,"_34":172,"_35":173,"_24":25,"_158":-5,"_27":174},{"_43":160,"_32":161,"_30":162,"_152":-5,"_41":42,"_40":155,"_153":25,"_38":163,"_13":63,"_34":20,"_35":164,"_24":25,"_158":-5,"_27":165},{"_43":150,"_32":151,"_30":56,"_152":-5,"_41":42,"_40":61,"_153":58,"_38":154,"_13":155,"_34":156,"_35":157,"_24":25,"_158":-5,"_27":159},"bd669c36-1b38-11f0-bb09-569c3dd06744","index.tsx","parentId","latest",["D",1744859095793],3,"http","/** @jsxImportSource https://esm.sh/react@18.2.0 */\nimport {\n listFiles,\n readFile,\n} from \"https://esm.town/v/std/utils@85-main/index.ts\";\nimport { renderToString } from \"npm:react-dom@18.2.0/server\";\nimport { Layout } from \"./Layout.tsx\";\nimport Markdown from \"./components/Markdown.tsx\";\nimport Post from \"./components/Post.tsx\";\n\nexport default async function (req: Request): Promise {\n const url = new URL(req.url);\n if (url.pathname === \"/\") {\n const files = await listFiles(import.meta.url);\n const posts = files.filter((file) => file.path.startsWith(\"posts/\"));\n const postContents = await Promise\n .all(posts.map((file) => readFile(file.path, import.meta.url)));\n\n return html(\n

Test Blog

Posts

\n {postContents.map((markdown, i) => (\n \n ))}\n

,\n );\n }\n if (url.pathname.startsWith(\"/posts/\")) {\n const markdown = await readFile(url.pathname, import.meta.url);\n return html(\n

My blog!

\n {markdown}\n

,\n );\n }\n return new Response(\"Not found\", { status: 404 });\n}\n\nfunction html(children: React.ReactNode) {\n return new Response(\n renderToString(\n \n {children}\n ,\n ),\n {\n headers: { \"content-type\": \"text/html;\" },\n },\n );\n}\n","label",[151],"847f6192-1b37-11f0-9778-569c3dd06744","deno.json","847f6282-1b37-11f0-9778-569c3dd06744",["D",1744858570834],"{\n \"$schema\": \"https://raw.githubusercontent.com/denoland/deno/348900b8b79f4a434cab4c74b3bc8d4d2fa8ee74/cli/schemas/config-file.v1.json\",\n \"lock\": false,\n \"compilerOptions\": {\n \"noImplicitAny\": false,\n \"strict\": false,\n \"types\": [\n \"https://www.val.town/types/valtown.d.ts\"\n ],\n \"lib\": [\n \"dom\",\n \"dom.iterable\",\n \"dom.asynciterable\",\n \"deno.ns\",\n \"deno.unstable\"\n ]\n },\n \"lint\": {\n \"files\": {\n \"include\": [\n \"deno:/https/esm.town/**/*\"\n ]\n },\n \"rules\": {\n \"exclude\": [\n \"no-explicit-any\"\n ]\n }\n },\n \"node_modules_dir\": false,\n \"experimental\": {\n \"unstable-node-globals\": true,\n \"unstable-temporal\": true,\n \"unstable-worker-options\": true,\n \"unstable-sloppy-imports\": true\n }\n}",[161],"d58d9ce8-1b37-11f0-a211-569c3dd06744","Layout.tsx","39797c14-1865-405b-b663-fbf3d1899c7a",8,["D",1744858706836],1,"script","/** @jsxImportSource npm:react@18.2.0 */\nimport type { ReactNode } from \"npm:react@18.2.0\";\n\nexport function Layout({ children }: { children: ReactNode }) {\n return (\n \n \n \n \n Test Blog\n \n \n \n {children}\n \n \n );\n}\n",[167],"8482434e-1b37-11f0-b1c4-569c3dd06744",".vtignore","848244f2-1b37-11f0-b1c4-569c3dd06744",4,["D",1744858570839],".git\n.DS_Store\nnode_modules\nvendor",[176],"52c12398-1b37-11f0-9141-569c3dd06744","posts","accc06dc-1d49-41da-b8cc-2e8b68adc2d7",["D",1744858487353],"directory",[183],"bd4eac0c-1b38-11f0-b953-569c3dd06744","components","bd4eacca-1b38-11f0-b953-569c3dd06744",14,["D",1744859095660],[189],"pulls","branches","forks","envVars",{"_201":63,"_203":63},"connections",{"_201":63,"_202":63},"count","unfilledCount","emptyCount",{"_43":188,"_32":189,"_30":190,"_152":-5,"_41":42,"_40":191,"_153":58,"_38":240,"_13":63,"_34":186,"_35":-5,"_24":25,"_158":-5,"_213":241,"_27":242},{"_43":232,"_32":233,"_30":234,"_152":190,"_41":42,"_40":235,"_153":25,"_38":236,"_13":63,"_34":172,"_35":237,"_24":25,"_158":-5,"_213":238,"_27":239},{"_43":182,"_32":183,"_30":184,"_152":-5,"_41":42,"_40":171,"_153":58,"_38":229,"_13":63,"_34":186,"_35":-5,"_24":25,"_158":-5,"_213":230,"_27":231},{"_43":225,"_32":33,"_30":31,"_152":184,"_41":42,"_40":14,"_153":58,"_38":226,"_13":178,"_34":20,"_35":37,"_24":25,"_158":-5,"_213":227,"_27":228},{"_43":175,"_32":176,"_30":177,"_152":-5,"_41":42,"_40":178,"_153":58,"_38":222,"_13":63,"_34":20,"_35":180,"_24":25,"_158":-5,"_213":223,"_27":224},{"_43":166,"_32":167,"_30":168,"_152":-5,"_41":42,"_40":169,"_153":25,"_38":219,"_13":171,"_34":172,"_35":173,"_24":25,"_158":-5,"_213":220,"_27":221},{"_43":160,"_32":161,"_30":162,"_152":-5,"_41":42,"_40":155,"_153":25,"_38":216,"_13":63,"_34":20,"_35":164,"_24":25,"_158":-5,"_213":217,"_27":218},{"_43":150,"_32":151,"_30":56,"_152":-5,"_41":42,"_40":61,"_153":58,"_38":212,"_13":155,"_34":156,"_35":157,"_24":25,"_158":-5,"_213":214,"_27":215},["D",1744859095793],"children",[],[151],["D",1744858570834],[],[161],["D",1744858706836],[],[167],["D",1744858570839],[],[176],"bd6a0146-1b38-11f0-a940-569c3dd06744",["D",1744859095795],[],[183,33],["D",1744858487353],[207],[183],"bd62dc5e-1b38-11f0-9d58-569c3dd06744","Markdown.tsx","bd62dd8a-1b38-11f0-9d58-569c3dd06744",15,["D",1744859095791],"/** @jsxImportSource https://esm.sh/react@18.2.0 */\n\nimport Markdown from \"https://esm.sh/react-markdown@9.1.0?deps=react@18.2.0\";\n\n// Custom renderer for markdown components to handle videos\nexport default function MarkdownWithVideo({ children }: { children: string }) {\n return (\n {\n // Check if the image URL is a video file\n const src = props.src || \"\";\n const isVideo = src.match(/\\.(mp4|webm|ogg|mov)$/i);\n\n if (isVideo) {\n return (\n \n );\n }\n\n // Regular image\n return ;\n },\n a: ({ node, ...props }) => {\n const href = props.href || \"\";\n const isVideo = href.match(/\\.(mp4|webm|ogg|mov)$/i);\n\n if (isVideo && props.children?.[0] === href) {\n return (\n \n );\n }\n\n return ;\n },\n }}\n >\n {children}\n \n );\n}\n",[],[189,233],["D",1744859095660],[205],[189],["D",1744858487353],{"_101":100,"_108":104},{"_101":100,"_102":-5,"_103":104,"_18":54,"_105":106,"_107":25},{"_13":86,"_32":87,"_43":42,"_88":44,"_89":90,"_91":92,"_93":50,"_94":95,"_96":97,"_98":45,"_99":100},"ctx",{"_79":-5,"_130":280,"_281":282,"_283":284,"_285":25,"_286":25,"_287":25,"_288":58,"_289":-5,"_290":-7,"_291":-7,"_292":63,"_293":25,"_294":25,"_295":-5,"_296":25,"_297":25,"_298":25,"_299":-5},"ENV",{"_251":252,"_253":254,"_255":87,"_256":257,"_258":259,"_260":261,"_262":263,"_264":265,"_266":267,"_268":269,"_270":271,"_272":273,"_274":275,"_276":277,"_278":279},"REACT_APP_SENTRY_DSN","https://586020d86f05489db63a554690acf1e9@o1398359.ingest.sentry.io/6724499","RENDER_GIT_COMMIT","e8c4b7030cb7600e4eb0736b15f422c8b8bd130f","RENDER_GIT_BRANCH","POSTHOG_API_TOKEN","phc_nmoyuAkStEZuUp69rYlg1DZgrIt19Gx0Y4Hwf8tGgJP","POSTHOG_API_HOST","https://wart.val.town","WEB_API_TEMPLATE","https://{val}.web.val.run","APP_URL","https://www.val.town","MODULE_URL","https://esm.town","VANITY_WEB_API_TEMPLATE","https://{label}.val.run/","DENOLS_URL","https://lsp.val.town","NODE_ENV","production","CLOUDFLARE_TURNSTILE_SITE_KEY","0x4AAAAAACtaIZJH7s9rBMZ6","GOOGLE_CLIENT_ID","875989696899-jtsqkhlbdv5jrlsk8631p7ipjg3c6o62.apps.googleusercontent.com","STRIPE_PUBLISHABLE_KEY","pk_live_51N2zvWEpZTTLipIkVEwXrUG9AT0yeOOEYxszarZT1jpsZV58Ly6wlg3SltZpHN26CUalOBmUSY7adQRQiSkCZz2500qSXNkf8Y","API_URL","https://api.val.town",[],"preferencesKeybindings","default","preferencesTheme","light","preferencesFixers","preferencesCopilot","preferencesSelectionAi","preferencesCloseBrackets","preferencesChatPanelState","preferencesDprint","preferencesDenofmt","notificationCount","flagDenols","isBusinessOrgMember","businessOrgHandle","isBusinessOrgAdmin","isHigherTownieTier","navCollapsed","currentOrgId"]

Diff · v17