d2js: Support Relative Imports

[x-delfino]

Adds support for relative imports for d2js

The main change is through adding InputPath to CompileRequest. This allows for a custom path to be set for the entry point within the provided filesystem e.g.:

import { D2 } from '@terrastruct/d2';

const d2 = new D2();

const fs = {
  "project.d2": "a: @import",
  "import.d2": "x: {shape: circle}",
}

const result = await d2.compile({
    fs,
    inputPath: "project.d2",
    options: {
        sketch: true
    }
});
const svg = await d2.render(result.diagram, result.renderOptions);

Minor change of throwing any errors in the elk graph generation for easier debugging

I haven't added it to the customizable.html example - don't know how complex you want that example to get but I can add another text area and some input boxes for filenames if needed

Fixes #2301

[x-delfino]

realised this might not quite fix #2301 - I'm not sure if they were asking for a more dynamic import e.g. you don't have to read the files from disk until d2 compile time

I was having a think about approaches for this - I think we can pass callbacks from js to wasm. could potentially define something that implements the fs.FS interface that just calls some js callbacks to read from files, and this could be passed around instead. I don't think you would be able to pass custom callbacks (which would be especially useful in browser environments), due to all messages to webworkers being serialised

this issue is likely relevant when people have a lot of/large d2 files, but would have a bigger impact on local bundling

[alixander]

I'm not sure if they were asking for a more dynamic import e.g. you don't have to read the files from disk until d2 compile time

This just comes down to the API. In the CLI interface, we pass a real file system. In the JS interface, we pass a virtual filesystem of a string -> string map. If users want to load files at runtime, the interface would have to allow other types, like string -> callback map. We wouldn't actually implement reading the files from disk, that's for the user to do in their callback, we just need to accept that type.

I can see both being useful. This PR solves imports for one of the use cases, but indeed not the one the issue is referring to.

[alixander]

Thanks!

[x-delfino]

This just comes down to the API. In the CLI interface, we pass a real file system. In the JS interface, we pass a virtual filesystem of a string -> string map. If users want to load files at runtime, the interface would have to allow other types, like string -> callback map. We wouldn't actually implement reading the files from disk, that's for the user to do in their callback, we just need to accept that type.

I can see both being useful. This PR solves imports for one of the use cases, but indeed not the one the issue is referring to.

yep got it - have got a proof of concept working for loading files at runtime using this approach. will raise a PR once it's ready

[alixander]

lgtm, just a merge conflict from your other PR

[x-delfino]

that should be resolved now :)