I do think it's more painful to distribute files when you're a distributed as a single binary vs scripts, since the latter has to figure out bundling of files anyway.
It's cool that it fits into golang's readable file system interface so it can be used polymorphically. I don't know if golang has very complete interfaces for a read and write file system that could be used for a full vfs. If it does, that's nice, and a starting point for a similar vfs! I'm also not sure whether it should go into the standard library or not.
Zip files are created in such a way that they can be a part of an executable file. (This is how self-extracting archives used to work.) Support for reading zip files is lightweight, and is present almost everywhere.
A ZIP fork embedded into the executable should be an obvious read-only VFS implementation. Bring your assets with you, even maybe build them with the standard zip utility.
It should take relatively few LOCs, provided that libzip is already linked into the executable anyway.
I get it, I've implemented things for tests, I'm just wondering if this shouldn't be solved at an OS level.
--- update
Let's put this another way, my code does effectively, child_process.spawn('something-that-reads-and-write-a-file')
now I'm back to the same issue. To test I need a virtual file system. Node providing one won't help.