search

decker-edu / decker

A markdown based tool for slide deck creation.
GNU General Public License v3.0
60 stars 15 forks source link

static-resource-dirs Semantics broken? #71

Closed marcerich closed 11 months ago

marcerich commented 11 months ago

The semantics of the static-resource-dirs variable only copies content which actually is referenced in the markdown sources. E.g., if a you include an html as an iframe like:

![](/assets/calendar-where-when/dist/index.html)

But the index.html relies on a local css file which also is in /assets/calendar-where-when/dist/, this one is not copied over. I am not sure 100% but this semantics seemed to be at least in my memory different in the past, where everything under static-resource-dirs was copied to the public folder. Even if not, would the latter not be the correct behavior? Otherwise it would be very complicated to use it in cases like the one described.

monofon commented 11 months ago

References inside index.html cannot cannot be known by decker without parsing the HTML. Even then, dynamic references from Javascript (with fetch) would still be missed.

static-resource-dirs:
  - assets

will unconditionally and recursively copy your assets dir to public an make it available at runtime.

marcerich commented 11 months ago

References inside index.html cannot cannot be known by decker without parsing the HTML. Even then, dynamic references from Javascript (with fetch) would still be missed.

Exactly, that is what I wrote ;)...

static-resource-dirs:
  - assets

will unconditionally and recursively copy your assets dir to public an make it available at runtime.

Exactly, that is what I wrote ;)...but it didn't for my example.

Whatever is worth, I duplicated by hand the old (it seems bogues) yaml entry and after a repeated manual character by character comparison (which did not show any differences) deleted the old one. Guess what, the error is gone and I can't reproduce it anymore for some insight ;(... I can only assume, one of the whitespaces in the old version must have been a non-printable character which the parser could not digest or something like. Felt at least like the good 'ol makefile mistakes...