On Sun, Aug 5, 2018, 5:35 AM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Sun, Aug 5, 2018, 00:43 Greg Sheremeta
<greg(a)gregsheremeta.com> wrote:
>
>
> On Sat, Aug 4, 2018, 3:25 PM Miro Hrončok <mhroncok(a)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(a)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)
>>
>
> Thanks - I'll do that this week and share here.
>
>
>> 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.
>>
>
> Old apps that use a script reference to say jquery can continue to use
> the js-jquery package. But most apps today are using libraries that aren't
> packaged (like react). The compiled payloads are simply packed in the app
> rpm, usually with a file name something like main.hash.js (one for each
> chunked output).
>
>
>>
>> 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...
>>
>
> Indeed, the build would use npm or yarn to get the JS. (the app author
> writes this into the build. Not something a packager would do.)
>
The problem with that approach is that there is no (and there cannot be
cannot be) internet access during package builds.
For offline rpm builds, what I've seen on other teams is people are taking
the entire node_modules dir (containing all the JavaScript libraries that
were downloaded by yarn or npm), zipping it, and using it as a Source. We
are going to use that approach for my team's projects too.
FWIW, I think the offline builds requirement is also something that should
be reconsidered, but that's outside the scope of this conversation.
Fabio
>
>> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>>
> _______________________________________________
> packaging mailing list -- packaging(a)lists.fedoraproject.org
> To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproje...
>
_______________________________________________
packaging mailing list -- packaging(a)lists.fedoraproject.org
To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproje...