On Sun, Aug 5, 2018, 5:35 AM Fabio Valentini <decathorpe@gmail.com> wrote:
On Sun, Aug 5, 2018, 00:43 Greg Sheremeta <greg@gregsheremeta.com> wrote:


On Sat, Aug 4, 2018, 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)

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@lists.fedoraproject.org
To unsubscribe send an email to packaging-leave@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.fedoraproject.org/message/WUBMK2QQHEDY5NF5ESSEJ2OB3MUVNKYF/
_______________________________________________
packaging mailing list -- packaging@lists.fedoraproject.org
To unsubscribe send an email to packaging-leave@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.fedoraproject.org/message/HLJX2NUCLHX7XNHFIQXFHNVDINSVRKFY/