On Sat, Aug 4, 2018, 4:30 PM Nico Kadel-Garcia <nkadel@gmail.com> wrote:
On Sat, Aug 4, 2018 at 3:25 PM, Miro Hrončok <mhroncok@redhat.com> wrote:
> On 4.8.2018 12:23, Greg Sheremeta wrote:
>>
>> On Sat, Aug 4, 2018 at 3:48 AM Miro Hrončok <mhroncok@redhat.com
>> <mailto:mhroncok@redhat.com>> wrote:
>>
>>     On 4.8.2018 01:17, Greg Sheremeta wrote:
>>      > Hi,
>>      >
>>      > This page
>>      > https://fedoraproject.org/wiki/Packaging:JavaScript
>>      > is terribly outdated. Even when it was created years ago, IMO the
>>     advice
>>      > was questionable. Today, it's definitely bad advice.
>>      >
>>      > Modern web applications use webpack for JavaScript. With webpack,
>>      > JavaScript is minified and bundled, and sometimes assets are even
>>      > injected. I realize bundling libraries is bad for an old-school
>>      > RPM-based application. But no one packages JavaScript into RPMs
>>     (try to
>>      > find react and friends), and the page is leading to confusion on
>>     my team.
>>      >
>>      > To prevent confusion, acceptable options would be: either simply
>>      > deleting the page, or placing a giant "don't follow this outdated
>>      > advice" banner at the top.
>>
>>     We don't generally do either of those. If the guidelines are outdated,
>>     they need to to be updated, not deleted.
>>
>>
>> Ok. Then I suggest this page be updated to roughly say client-side
>> JavaScript should not be packaged in RPMs.
>
>
> Feel free to propose a ticket at http://pagure.io/packaging-committee/
>
> Best tickets include:
>
>  * draft guideline on the wiki and diff
>  * rationale (explained in detail, so even nonexperts in the given domain
> (here JS) could get the reasoning behind it)
>
> As for now, I personally don't like your idea, as it lacks some explanation
> about what should the packager do if they need to package a web application
> that uses client side JS.
>
>
> For example: the app ships client side JS bundled, but minified.
> Or: the app expects me to run npm install to get the client side JS.
> etc...

It looks like he wants webpacks, instead of RPMs. This has been tried
before, with CPAN, pip, ant, maven, and gradle, and they run into the
same issues. They're very language specific, they're bad at avoiding
conflict with other installed software, they're bad at auditing or
reporting what contents deposited on your filesystem come from what
application. Those issues are not all the fault of the packaging
system: much of it is the fault of software authors who cannot follow
conventions about how to name and where to install their software.
Frankly, the enforced rules and hard-won lessons of RPM bundling have
helped tremendously. Some tools, like cpan2rpm and py2pack, have even
gotten useful for RPM bundling packages from such software building
and bulding tools.

It sounds like, if webpacks are going to be supported for RPM
packages, then it needs wrappers to pack them into RPM bundles.
Perhaps something like "cpan2rpm" could be done for webpacks?

The JavaScript package manager is npm or yarn, actually.

It is a similar situation to previous languages. However, it's worse here because of how fragmented JavaScript is. Trying to wrap modules in RPMs isn't going to scale.