You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As I was reviewing tests in #277, I realized that the fileReference name is a path (like ./test.png), not a basename (test.png). In particular, if you have two fileReferences in the same page, say one to test.png and the other to ./test.png, the name field is arbitrarily the one or the other.
We can normalize that name by removing a starting ./, but it still bugs me that the name is a path (especially since we also have a path field). Note that in build.ts we use this name as a path, when the file is not in the page directory.
The text was updated successfully, but these errors were encountered:
The name has to match what is passed to FileAttachment exactly, so that we can look it up in the map. That is, unless you want to rewrite the argument we pass to FileAttachment, or do some further normalization in resolveFile.
I agree it would be better if the exposed file.name were just the name and not a path… That’s not something we ever ran into before with notebooks since we didn’t allow paths. 😅
As I was reviewing tests in #277, I realized that the fileReference name is a path (like
./test.png
), not a basename (test.png
). In particular, if you have two fileReferences in the same page, say one totest.png
and the other to./test.png
, the name field is arbitrarily the one or the other.We can normalize that name by removing a starting
./
, but it still bugs me that thename
is a path (especially since we also have a path field). Note that in build.ts we use this name as a path, when the file is not in the page directory.The text was updated successfully, but these errors were encountered: