• Bug#1103615: [Pkg-javascript-devel] Bug#1103615: node-dompurify: please

    From =?UTF-8?B?SsOpcsOpbXkgTGFs?=@21:1/5 to All on Sun Apr 20 13:30:01 2025
    Le dim. 20 avr. 2025 à 09:09, Paul Gevers <elbrus@debian.org> a écrit :

    Hi,

    On Sat, 19 Apr 2025 19:28:11 +0200 Paul Gevers <elbrus@debian.org> wrote:
    I was struggling to package the latest version of `liferea` because I didn't want to use the upstream vendored purify (and handlebars). It
    turns out that the Debian version of node-dompurify is too old. Is it reasonable to upgrade?

    For the purpose of liferea, it might be relevant to say that apparently
    it's using an ESM version of dompurify (and handlebars). As I'm all new
    to this, upstream pointed me at [1] which explains a bit. I have no idea
    if it's reasonably feasible for the Debian node ecosystem to provide
    both flavors (by means of a ESM wrapper around the CJS flavor if I
    understand correctly).


    Good question ! The answer is that it's not needed:
    nodejs 20.19.0 can "require(esm)" [1] so a CJS module is no longer locked
    out using ESM modules.
    The other way around (import a CJS module form an ES module) has always
    been possible.
    All nodejs modules will switch to ESM, and in a far future "require" will
    be a thing of the past.

    For browsers, it's a little bit different:
    "require" is not supported in browsers, but "import" is supported.
    However, 99.99% if not 100% of modules for browsers are bundled, and the bundler is supposed to behave
    like nodejs above, so we're back to the first situation.



    [1] file:///usr/share/doc/nodejs/api/modules.html#loading-ecmascript-modules-using-require





    I guess for now I need to consider my options for liferea and I'm nearly convinced the best is to not try to ship the latest upstream version at
    this stage of trixie and leave that to forky.


    Yes, "soft freeze".

    <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Le dim. 20 avr. 2025 à 09:09, Paul Gevers &lt;<a href="mailto:elbrus@debian.org">elbrus@debian.org</a>&gt; a écrit :<br></
    <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>

    On Sat, 19 Apr 2025 19:28:11 +0200 Paul Gevers &lt;<a href="mailto:elbrus@debian.org" target="_blank">elbrus@debian.org</a>&gt; wrote:<br>
    &gt; I was struggling to package the latest version of `liferea` because I <br> &gt; didn&#39;t want to use the upstream vendored purify (and handlebars). It <br>
    &gt; turns out that the Debian version of node-dompurify is too old. Is it <br> &gt; reasonable to upgrade?<br>

    For the purpose of liferea, it might be relevant to say that apparently <br> it&#39;s using an ESM version of dompurify (and handlebars). As I&#39;m all new <br>
    to this, upstream pointed me at [1] which explains a bit. I have no idea <br> if it&#39;s reasonably feasible for the Debian node ecosystem to provide <br> both flavors (by means of a ESM wrapper around the CJS flavor if I <br> understand correctly).<br></blockquote><div><br></div><div>Good question ! The answer is that it&#39;s not needed:</div><div>nodejs 20.19.0 can &quot;require(esm)&quot; [1] so a CJS module is no longer locked out using ESM modules.</div><div>The other
    way around (import a CJS module form an ES module) has always been possible.</div><div>All nodejs modules will switch to ESM, and in a far future &quot;require&quot; will be a thing of the past.</div><div><br></div><div>For browsers, it&#39;s a little
    bit different:</div><div>&quot;require&quot; is not supported in browsers, but &quot;import&quot; is supported.</div><div>However, 99.99% if not 100% of modules for browsers are bundled, and the bundler is supposed to behave</div><div>like nodejs above,
    so we&#39;re back to the first situation. </div><div><br></div><div><br></div><div><br></div><div>[1]</div><div>file:///usr/share/doc/nodejs/api/modules.html#loading-ecmascript-modules-using-require</div><div><br></div><div><br></div><div><br></div><div>
     </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    I guess for now I need to consider my options for liferea and I&#39;m nearly <br>
    convinced the best is to not try to ship the latest upstream version at <br> this stage of trixie and leave that to forky.</blockquote><div><br></div><div>Yes, &quot;soft freeze&quot;.</div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?SsOpcsOpbXkgTGFs?=@21:1/5 to All on Mon Apr 21 11:30:01 2025
    Le lun. 21 avr. 2025 à 10:12, Paul Gevers <elbrus@debian.org> a écrit :

    Hi Jérémy,

    Thanks for the reply.

    On 20-04-2025 13:21, Jérémy Lal wrote:
    Good question ! The answer is that it's not needed:
    nodejs 20.19.0 can "require(esm)" [1] so a CJS module is no longer
    locked out using ESM modules.
    The other way around (import a CJS module form an ES module) has always been possible.


    As I understand it, liferea is already ESM and my problem is that the
    code apparently assumes that node-dompurify (and handlebars) is ESM too.
    So far, I have never needed to fix javascript in a more than trivial
    manner, so I don't know where to start here. My fundamental question is
    what do I have to do to build liferea with the Debain shipped
    node-dompurity (and handlebars) instead of the vendored version? liferea
    uses the file during the build and embeds it in the executable, but as
    can be seen from my discussion in the upstream bug tracker [1], using
    the current versions in Debian doesn't work and upstream suggested that node-dompurify needs the change. I understand you say it should be
    trivial to fix on the liferea side? (The include happens here [2], for handlebars it's here [3]. I tried commenting them out and adding a
    <script> here [4] but that seems to be too simple.)


    For handlebars, it should work all right as it is,
    for dompurify, first fix the path you copy it from, use: /usr/share/nodejs/dompurify/dist/purify.es.mjs

    Then to fix the version mismatch, you can use this patch:

    diff --git a/js/htmlview.js b/js/htmlview.js
    index d6f4a9f..d1d4f69 100644
    --- a/js/htmlview.js
    +++ b/js/htmlview.js
    @@ -22,6 +22,8 @@
    import { render, template } from './helpers/render.js';
    import DOMPurify from './vendor/purify.min.js';

    +const purify = DOMPurify(window);
    +
    window.debugflags = 0;

    function prepare(baseURL, title) {
    @@ -227,7 +229,7 @@ function contentCleanup() {

    // Run DOMPurify
    let content = document.getElementById('content').innerHTML;
    - document.getElementById('content').innerHTML = DOMPurify.sanitize(content);
    + document.getElementById('content').innerHTML = purify.sanitize(content);

    // Fix inline SVG sizes
    const svgMinWidth = 50;

    <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Le lun. 21 avr. 2025 à 10:12, Paul Gevers &lt;<a href="mailto:elbrus@debian.org">elbrus@debian.org</a>&gt; a écrit :<br></
    <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa