Description

Let's allow mounting filesystem directories in Blueprints.

Rationale

For local Playground, that would be useful for mounting:

• Plugins and themes from arbitrary directories in Node.js
• Every workspace folder in a VS code extension

In the browser, that would be useful for mounting:

• Local directories using the Filesystem API
• Origin Private File System directories
• Arbitrary filesystems like the FS abstraction provided by the online version of VS Code

Implementation

Blueprints are isomorphic and we'd need an isomorphic of handling mounts. A mounted "resource" would have to be an abstraction so that every platform can defer to a platform-specific implementation. We already have a notion of resources, perhaps it would fit in here, too:

{
    "steps": [
        {
            "step": "mount",
            "resource": {
                "resource": "localPath",
                "path": "gutenberg"
            },
            "vfsPath": "wp-content/plugins/gutenberg"
        }
    ]
}

Actually – should mounts be steps? The only two reasons I can think of is to mount them not earlier than X or to unmount them later. Neither seems compelling, so perhaps this would be a better API:

{
    "steps": [ /* ... */ ],
    "mounts": {
        // Keyed by vfsPath:
        "wp-content/plugins/gutenberg": {
            "resource": "localPath",
            "path": "gutenberg"
        }
   }
}

However, localPath doesn't make sense on the web where JavaScript only has access to the directory selected by the user. Here's yet another idea:

{
    "steps": [ /* ... */ ],
    "mounts": {
        // Keyed by vfsPath:
        "wp-content/plugins/gutenberg": {
            /**
             * Source from the `gutenberg` host directory when running locally.
             * Source from the `gutenberg` opfs directory when running in the browser.
             * Source from the `gutenberg` VSCode.dev directory when running there.
             */
            "path": "gutenberg",
            "priority": [
                // Source it from opfs if available, otherwise try the next one
                "opfs",
                // Ask the user to pick a directory if it can be done in the current runtime
                "localDirectoryPicker",
                // Treat `gutenberg` as a path on the host when that's supported
                "hostPath"
            ]
        },
        // Or use a shorthand notation
        "wp-content/plugins/friends": "friends"
   }
}

But then, with few mounts, it would be a bad UX to ask the user to select five directories in the browser. It would be much more convenient to just pick one and have Blueprints figure it out from there. Let's keep thinking about this.

Here's a few open questions:

• Should it be possible to write a platform-specific Blueprint that would work e.g. on the web but not in Node?
• What would be a practical application of such an isomorphic mapping declaration?
• What syntax would an Isomorphic Blueprint use to provide defaults for different platforms? E.g. mount a specific local path in Node.js, but in the browser display a directory picker and have the user select the path.