Support for language agnostic dependency hints

[jramke]

Hey,

i wanna to use jsrepo in a TYPO3/Fluid (php) project. Im pretty sure you never heard of these 😅, but Fluid is the rendering engine for the TYPO3 CMS, both written in php. Fluid files are just .html files but with custom xml bases "viewhelpers". For example using a Button component could look like this

<div class="my-class">
  <ui:button>Hello World</ui:button>
</div>

Or loading a script looks like this:

<f:asset.script src="path/to/my/script.js" />

Right now, only script tags and stylesheets are recognized as dependencies in HTML files, as I saw here #308, but that doesn’t work in this case.

I wanna suggest the idea of language-agnostic and fine-tunable dependency hints.
This could look something like this in a dialog component:

<!-- jsrepo:dependency='../Button.html' -->
<!-- jsrepo:dependency='../dialog.js' -->

<div class="dialog">
  <ui:button asTrigger>Trigger</ui:button>
  <div>Content</div>
</div>
<f:asset.script src="../dialog.js" />

The comments then would get removed when importing the block in a project.

I think other popular tools like blade or twig could also benefit from this. It would allow jsrepo to be used in way more scenarios.

I would love to hear what you think about this, @ieedan

Best,
Joost

[ieedan]

I have thought about dependency hints before but I think it generally goes against my goal of making it as easy as possible.

Would a better solution be to simply start treating 'src' the same as a dependency?

[jramke]

Thanks for the super quick response!

I don’t think resolving src brings much benefit. For instance, there's a vite extension that looks like this: <vite:asset entry="..." />. I’m worried this might add more complexity than it solves.

I pictured the hints as an extra feature, keeping it plug in play for most users. But if dependency resolving isnt supported for a certain language, we could enable this with a feature flag to help out.

[ieedan]

Honestly I am wondering if at that point we would be better off going the shadcn route of not resolving dependencies and instead requiring users to manually provide them with an external config?

Obv we would keep the current behavior as well and this would be opt in but this would allow for more granular control of the registry.

I am kinda against type hints a bit because it's going to require us to consider comments when parsing which could require additional dependencies since the parsers I am using currently have varying support.

[jramke]

Yeah an external config sounds nice too and most likely less error prone