[Pkg-javascript-devel] Plan for legacy rollup plugins in bullseye (was Re: node-rollup-plugin-inject 4.0.2+~3.0.2-1 MIGRATED to testing)

[Xavier]

Le 25/10/2020 à 11:57, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-10-25 11:27:55)
>> Le 25/10/2020 à 09:06, Pirate Praveen a écrit :
>>>
>>> On 2020, ഒക്‌ടോബർ 25 10:09:13 AM IST, Debian testing watch <noreply at release.debian.org> wrote:
>>>> FYI: The status of the node-rollup-plugin-inject source package
>>>> in Debian's testing distribution has changed.
>>>>
>>>>  Previous version: (not in testing)
>>>>  Current version:  4.0.2+~3.0.2-1
>>>
>>> Are we going to maintain legacy versions of these plugins in bullseye? I agree adding them makes the transition easier, but removing the legacy copies should also be part of the plan to avoid maintaining multiple versions of these plugins.
>>
>> Hi,
>>
>> you're right, however there are a lot of outdated modules in JS Team
>> packages, and these rollup plugins have no known vulnerabilities.
>>
>> We can also facilitate transition using this way (using experimental of
>> course):
>>  * remove legacy module from any node-rollup-plugin-*
>>  * insert our own legacy modules in them including just:
>>    * /usr/share/nodejs/rollup-plugin-foo/package.json
>>
>>      { "name":"rollup-plugin-foo",
>>        "main":"index.js",
>>        "dependencies":{
>>          "@rollup/plugin-foo": "*"
>>        }
>>      }
>>
>>    * /usr/share/nodejs/rollup-plugin-foo/index.js
>>
>>      module.export = require("@rollup/plugin-foo");
>>
>> Note that transition of node-rollup-plugin-commonjs won't be easy
>> (remember 10.0.1+really.9.2.0). Same for node-rollup-plugin-node-resolve
> 
> Do I understand you correctly that you propose to ship legacy library 
> embedded with consuming packages?
> 
> That seems backwards to me - what would be the benefit?

Upstream chose to rename its rollup-plugin-foo to @rollup/plugin-foo.
For now, I modified all of them: I embedded in node-rollup-plugin-foo
both libraries:
 * main source is @rollup/plugin-foo
 * a component named "legacy" that embeds old node-rollup-plugin-foo

Most of them have non breaking changes. Then instead of keeping an
outdated library, I propose to install only @rollup/plugin-foo and add a
very simple /usr/share/nodejs/rollup-plugin-foo that returns
@rollup/plugin-foo (see above). This permits legacy removal and avoids
to maintain a lot of patches in nodejs packages that uses them. No
urgency for now since there are no security issues.

Some of @rollup/plugin-foo *have* breaking changes, at least
@rollup/plugin-commonjs and @rollup/plugin-node-resolve //(our legacy
node-rollup-plugin-{commonjs,node-resolve} are already outdated)//.
Propositions:
 1. keep packages with both libraries
 2. try to patch all packages that uses them, then remove "legacy"
    component (no urgency for now since there are no security issues)

> I think it is better to ship legacy library with non-legacy library, to 
> ease tracking of its continued need and maintain it where there is most 
> knowledge about the library, but I may be missing something...

Sorry, I didn't understand, would you like to keep current situation
(I'm OK with this) or remove legacy component (I'm OK too)?

I'm so sorry, my poor English (neither the help of Google Translator)
makes me unable to understand the meaning of "to ship" here (send in
package or send outside package?).

Cheers,
Xavier