[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)

[Jonas Smedegaard]

Quoting Xavier (2020-10-27 14:45:40)
> 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?).

Sorry for my sloppy language - "to ship" means "to include in our 
shipment" a.k.a. "to distribute".

Let me try again:

In my previous email I worried that your proposal was to _only_ include 
modern code in rollup plugin packages, and include a copy of old plugin 
code into each package that needed old code.  I.e. this:

 * pkg:node-rollup-plugin-foo
   + include modern @rollup/plugin-foo

 * pkg:node-bar-depending-on-old-foo
   + include old rollup-plugin-foo

 * pkg:node-baz-depending-on-old-foo
   + include old rollup-plugin-foo


I would prefer - and now think that this was your proposal (both now and 
before - that I simply misunderstood you before) - that we instead do 
this:

 * pkg:node-rollup-plugin-foo
   + include modern @rollup/plugin-foo
   + include old rollup-plugin-foo
   + Provides: node-rollup-plugin-foo (= $OLD)

 * pkg:node-bar-depending-on-old-foo
   + Depends: node-rollup-plugin-foo (= $OLD)

 * pkg:node-baz-depending-on-old-foo
   + Depends: node-rollup-plugin-foo (= $OLD)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20201027/89e451c9/attachment.sig>