nodejs August 2018

nodejs@lists.fedoraproject.org

4 participants
4 discussions

Source0 for nodejs modules
by Piotr Popieluch 04 Dec '18

04 Dec '18

The the Node.js guidelines say about Source0 [1]: "The canonical method for shipping most node modules is tarballs from the npm registry" and "This method [PP: tarbals from npm] should be preferred to using checkouts from git or automatically generated tarballs from GitHub." But I think that in following cases it would be better to use sources from the upstream project: 1) When the license is not included in NPM but is in upstream project. o Because we are not supposed to ship the license separate from the sources. 2) When the tests are not included. o In this case we need to download the sources from NPM and from upstream project, which seems redundant and a waste of work. 3) When NPM content is generated and source files are not in NPM. o This would mean to download sources from NPM and upstream project, delete the NPM sources in prep and generate the files again. Are there good reason to enforce the use of NPM sources which I am missing? What is your opinion? I would like to suggest to ad those three exceptions to the guidelines. Piotr [1]: https://fedoraproject.org/wiki/Packaging:Node.js?rd=Node.js/Packagers#Using…

4 5

Packaging the Javascript layer of Prometheus & Grafana
by Nicolas Mailhot 31 Aug '18

31 Aug '18

Hi, I'm currently investigating the packaging of Prometheus and Grafana in Fedora/Epel. Both are cutting-edge high-visibility complex applications written in Go, that map well to Fedora/Epel historical sysadmin userbase https://prometheus.io/ https://grafana.com/ I already spent a few months of work working on the Go layer, writing Golang-to-rpm plumbing, packaging guidelines, packaging and testing hundreds of spec files. It is finally looking like something that could end up in the distribution, even though there is still a ton of work to do plumbing-side to make Go packaging in Fedora simple and convenient. And I'd like to spend more time making this plumbing a reality. However, at the same time, the target apps can not be used, since they include a javascript layer, and I haven't packaged it. Prometheus provides a bundled copy of the javascript it needs, thus I supposed it could be packaged as-is, even though that is bad engineering and totally not what I did for the Go layer. https://github.com/prometheus/prometheus/tree/master/web/ui/static/vendor Grafana OTOH has a clean codebase with a build process that uses yarn to get third-party javascript https://github.com/grafana/grafana/blob/master/yarn.lock Therefore, I'm looking for help : 1. either pointers or advice on how to package this javascript cleanly or 2. ideally, people willing to take over this javascript packaging, so I can focus on finishing the Golang plumbing in Fedora I suppose this is also a test if a distribution like Fedora/Epel can still be used to deploy the kind of apps written in 2018, or if it's condemned to fade and be replaced by other approaches like containers. Regards, -- Nicolas Mailhot

3 5

Packaging the Javascript layer of Prometheus & Grafana
by Nicolas Mailhot 29 Aug '18

29 Aug '18

1 0

Installing npm tools
by Anatoli Babenia 13 Aug '18

13 Aug '18

I need to use `crm` tool from npm, which is not packaged, and using `npm install crx` I couldn't find the binary until I came across this article - http://2ality.com/2016/01/locally-installed-npm-executables.html It is not recommended way to do this, but for a problem oriented workflow it is still worthy to explain `npm bin`. If there is a way to install such binary utils in isolated environment without hurting system dependencies (Python virtualenv), I would be happy to follow. Making npm-installed packages global is not my goal.

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

nodejs August 2018