Package widgets into NPM package

[OnkelTem]

Instead of downloading embed.js and other widgets, they could be a part of an npm package.
We then could install it, require/import it, and have much more control over how widgets load and when.
It would also make comments appear faster and smoother.

[paskal]

I'll look into it shortly, I'm doing frontend rework at the moment. But I am thinking against NPM altogether, we had api package which had zero adoption since 2022 and I will drop now. In this AI age I think crystal clear API documentation should be enough to build their own frontend as they want, if they want to, and as far as I recall we never broke API compatibility.

[paskal]

Having now looked at this properly, I am going to decline it, and the reason is more specific than my earlier note suggested.

The blocker is authentication rather than packaging. The widget runs inside an iframe served from the Remark42 origin, and OAuth login depends on that: the login link opens a popup at <remark42>/auth/<provider>/login with a return URL pointing back at the iframe document, the provider redirects to Remark42, the cookie is set first-party there, and the popup closes itself. The widget then notices the popup has closed and re-fetches the user.

Import the widget into your own bundle and it renders in your page's origin instead. The auth cookie is then a third-party cookie for every request the widget makes, which Safari blocks outright today and Chrome is moving away from. Login would fail for a large share of visitors, and it would fail silently, since that flow polls for a user that never arrives rather than surfacing an error. The iframe is not an implementation detail we have not got around to removing; it is what makes login work.

The underlying want, control over when and how the widget loads, is already available without a package. window.REMARK42.createInstance(config) mounts a widget at the moment you choose, and destroy() tears it down, so lazy loading, route changes in a single-page app, and mounting on intersection are all doable against the embed script as it ships. #1714 has the current contract written out, including the parts that are easy to trip over.

For a genuinely custom frontend the supported path is the REST API, which is documented and has not broken compatibility. @remark42/api, the typed client we did publish, was removed in #2172 after seeing effectively no adoption since 2022; a thin wrapper over documented HTTP endpoints was not carrying its maintenance cost.

Closing #240, which asked for the same thing in 2019, alongside this.