Document gotchas when user's invocation asks SEA to perform FS calls against own VFS

[cspotcode]

The blog post lists as one of the requirements of VFS:

7 | No interference with valid paths in the file system

Not the same as the above, but worth including in documentation for any VFS implementation: will those files be exposed via clever invocations of bundled executables? This depends on where the VFS lives; what paths it uses.

For example if I bundle prettier into an executable and then run it, asking it to format a path that exists in the VFS: ./prettier ./prettier/__vfs__/index.js then I'm guessing I will see bundled source emitted to stdout.

I think this is fine, it's just a characteristic of the VFS that may be worth documenting. Wouldn't want users of SEA to assume bundled files are in any way secret without application-level safeguards.

---

Another thing that might crop up:

If I run ./globbing-tool './**/*', will it list the contents of the VFS? If the VFS exists at ./globbing-tool then ./globbing-tool/__vfs__/bin.js does match the glob.

If I run ./globbing-tool './**/* | bash-stuff then bash-stuff might try to read ./globbing-tool/__vfs__/bin.js and fail.

[RaisinTen]

will those files be exposed via clever invocations of bundled executables?

I don't think that's something we should expose to the end users because to them, it's just an executable file. If the single executable file is at location ./sea, being able to access something like ./sea/__vfs__/index.js is not something they should expect because that would treat ./sea as a directory and that is incorrect behavior at least w.r.t how the OS allows you to access certain file paths.

Also, the files bundled into the single executable is an internal component of the bundled application, so I don't think there's any reason why an end user would want to access that. If it's something that an application author expects their users to access, IMO such a resource should be placed somewhere on the real file system.

[ljharb]

That gets tricky tho when an fs operation is done dynamically, but i guess the vfs wrapper could do that dynamically as well.

[ovflowd]

Definitely! I would maybe go to lengths that maybe supporting dynamic imports could be tricky from day one. In the end, if the whole string gets constructed dynamically, we could instead of making the string interpolation within the fs statement, SEA could provide a Proxy for fs calls, and then analyze the final string that is sent to the fs methods

[cspotcode]

A list of scenarios can be created. Then the list can be checked against any proposed VFS implementation, to see which items on the list are supported, which are not, which have workaround, which have limitations or gotchas worth documenting. Depending on what goes on the list, not everything on the list needs to be supported.

A few items that can go on the list for starters: Static import, static require, dynamic import, dynamic require, passing argv values to FS calls, working directory is /, being able to manipulate VFS paths as strings vs URL objects

[jviotti]

I think we should definitely make the VFS transparent in the way that PKG (cc @jesec) has accomplished already. Otherwise, there are tons of existing modules out there that wouldn't work at all when packaged.

[RaisinTen]

FWIW, I have opened #28 to document all the requirements of the VFS, so feel free to put your suggestions there!