jimjam-slam / sverto

Add Svelte components to your Quarto documents
https://sverto.jamesgoldie.dev
MIT License
60 stars 3 forks source link

Improve project-relative path resolution #3

Closed jimjam-slam closed 1 year ago

jimjam-slam commented 1 year ago

When we convert our import_svelte references to dynamic ES bundle imports in the project pre-render, we presently assume the paths are relative to /site_libs/quarto-ojs, so we prefix ./../.. to the path.

If project-relative paths (eg. /Circles.svelte) are left alone, they resolve to Rollup's node_modules folder instead of the project root. They'll require separate handling to be supported properly (if, indeed, they can be at the project pre-render stage!).

We may also need to check the edge case that a document is being rendered rather than a project (in which case the libraries go in [name]_files, not site_libs), but given we rely on project infra anyway, maybe this isn't a big deal.

jimjam-slam commented 1 year ago

Actually, the problem is bigger:

For example, in this directory structure:

index.qmd
posts/
  animals/
    cows.qmd     # imports CowChart.svelte
    CowChart.svelte

In cows.qmd, import_svelte("CowChart.svelte") needs to become import("CowChart.js"). But the Svelte compiler needs to receive the path /posts/animals/CowChart.svelte.

We use the file .sverto/sverto-imports to track what goes to the Svelte compiler. Currently it gets the path relative to the Quarto doc, but it really needs to be relative to the project.

(I didn't notice this problem before because in my testing, cows.qmd would use a shared Svelte component that was up in the project root 🤦🏻‍♂️ )

jimjam-slam commented 1 year ago

We append the Svelte import to .sverto/sverto-imports at:

https://github.com/360-info/sverto/blob/f7448e1305c075041a5608bda73b6dc2ee1c7dd0/_extensions/sverto/create-imports.lua#L78

If qmd_path was in scope here, we could concatenate it with svelte_path (with perhaps some edge cases around file path construction) and that would be it. But qmd_path appears to be nil at this point, suggesting a scoping issue when running doc:walk.