(Bug report) share.js broken on share pages on v0.91.3-beta

[kleutzinger]

Description

I can't call fetchNote on my share pages' clientside javascript because the builtin share.js has some error. This error happens on firefox and chromium when visiting any shared page.

Uncaught SyntaxError: export declarations may only appear at top level of a module

This is the share.js my browser (firefox) recieves when visiting a page (i think the error is from the 2nd to last line, export {}; ).

/**
 * Fetch note with given ID from backend
 *
 * @param noteId of the given note to be fetched. If false, fetches current note.
 */
async function fetchNote(noteId = null) {
    if (!noteId) {
        noteId = document.body.getAttribute("data-note-id");
    }
    const resp = await fetch(`api/notes/${noteId}`);
    return await resp.json();
}
document.addEventListener("DOMContentLoaded", () => {
    const toggleMenuButton = document.getElementById("toggleMenuButton");
    const layout = document.getElementById("layout");
    if (toggleMenuButton && layout) {
        toggleMenuButton.addEventListener("click", () => layout.classList.toggle("showMenu"));
    }
}, false);
export {};
//# sourceMappingURL=share.js.map

TriliumNext Version

0.91.3-beta

What operating system are you using?

Other Linux

What is your setup?

Local + server sync

Operating System Version

Linux 6.12.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 18 Jan 2025 02:26:57 +0000 x86_64 GNU/Linux

Error logs

No response

[pano9000]

when I try the same with the latest code on develop branch, I actually get a different MIME type conflict error, that blocks loading of share.js altogether - so I do not get your error message:

Something along the lines of
Loading the resource "http://localhost:8080/assets/v0.91.2-beta/app/share.js" was blocked due to a MIME type conflict ("application/json") (X-Content-Type-Options: nosniff).

Will need to research a bit here.

Was it working for you on the previous beta release by any chance?

Edit:

with tag 0.91.1 it was working, with 0.91.2 I get the above error, so must be some regression that happened in between those two version.

Will take a look this evening to pinpoint the issue

[kleutzinger]

It was working on 0.91.1-beta which was the last version I used.

I saw the same thing you did (mime issue) on dev branch when running locally, though I never tried actually deploying dev to a real server.

[pano9000]

seems the behaviour got added with b3b8ae4
The commit before that does not give me any of those errors.

edit: when I run locally in "non-Dev" mode, it also throws me a similar issue as you have above:
JS Error: Uncaught error: Message: SyntaxError: export declarations may only appear at top level of a module, URL: http://localhost:8080/assets/v0.91.2-beta/app-dist/488.js

Will take a closer look at what could be the cause of this :-)

edit 2025-01-23:

some notes here, coming closer to solving the mystery :-)

non-dev mode (i.e. , TRILIUM_ENV=anything_but_dev)

When in non-dev mode , the share.js file is statically served and accessible under the path http://localhost:8080/assets/v0.91.2-beta/app/share.js.
However the share page temple (share.ejs) is looking for the file at /assets/v0.91.2-beta/app-dist/share.js (app vs app-dist), as we can see in the network activity tab.

That path does not exist and returns a JSON error message about a not found route (this explains the MIME Type conflict :-)).

dev mode (i.e. , TRILIUM_ENV=dev)

The share page template is looking for the file at /assets/v0.91.2-beta/app/share.js, but it does not exist there, and neither does it at /assets/v0.91.2-beta/app-dist/share.js in my case running this on localhost

edit 2025-01-24:

regarding non-dev mode remark above: scratch that -> that was caused due to the incomplete npm run scripts in package.json, which are not rebuilding webpack, if you don't do it manually – which I forgot :-)
For dev issue is still valid -> see below attached PR

[kleutzinger]

note: I temporarily worked around this error by copying the two js statements to the top of my ~shareJs(inheritable)=public-note-client.js file. I did not copy the export line.

Thanks for looking into this!

[pano9000]

quick question: may I know how you installed your version?
Was it via Docker by any chance?

[pano9000]

quick update on this again:

The share.js is not build by webpack – In the "build/packaging process" (e.g. via Docker) the "original" share.js is actually manually copied from the ./src/public/app into the an app-dist folder, where the remaining webpack bundled code remains.
Not sure, why the share.js in the beta release even contained this export {} line at all – that should only happen, when webpack "treats" the file.

I'm still looking into finding a way to make this work with Webpack directly though to get rid of this extra copying step.
Currently I am running into the issue that Webpack "tree-shakes" (aka removes) the fetchNote function, because it sees it as "dead code", since it is not used anywhere in the code.

edit:
I have found a "hacky" way to prevent that from happening (involving the window object), but will continue to see if there is more cleaner way though.

[kleutzinger]

quick question: may I know how you installed your version? Was it via Docker by any chance?

Yes, docker. I deployed it to my dokku instance via sudo dokku git:from-image trilapp triliumnext/notes:v0.91.3-beta

[pano9000]

ok, thanks for the confirmation.
#1048 should fix the issue, and should hopefully be merged soon, ready for the next release.