nodejs November 2015

nodejs@lists.fedoraproject.org

9 participants
7 discussions

Source0 for nodejs modules
by Piotr Popieluch 03 Dec '18

03 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

lodash
by Tom Hughes 14 Dec '15

14 Dec '15

I've been putting my mind to trying to figure out the mess of craziness that is lodash with the aim up updating it... There are basically two upstream repos I believe: https://github.com/lodash/lodash-cli - the build tool https://github.com/lodash - the actual source Currently have three source packages: nodejs-lodash-cli - generates nodejs-lodash-cli nodejs-lodash - generates nodejs-lodash nodejs-lodash-node - generates many packages It's very dubious to what extent the sources those packages are using are the genuine root source though. The basic story upstream is that the main lodash repo has a build script that can generate a lodash.js single file build and the lodash tool in the lodash-cli repo can then generate all sorts of different builds of lodash from that. Except that lodash-cli is a node program that does require("lodash") but the may the lodash npm is build is to use the lodash command line tool so that's all a bit circular. My feeling is that we should move to a single source package that uses both the upstream repos as sources. The strategy would then be something like this: cd lodash node lib/main/build.js [generates dist/lodash.js] cd ../lodash-cli mkdir node_modules ln -s ../../lodash/dist/lodash.js node_modules lodash modularize modern exports=node -o nodejs-lodash and then a serious of further lodash commands to generate the different builds. It could then spit out a number of different RPMs corresponding to the many different versions that the lodash project publish to the npm registry and also some js- versions if we wanted. My gut feeling is we should all three current source packages and create a new one just called lodash that can spit out whatever node and non-node ones we need but we could also repurpose the existing nodejs-lodash package as the source. So, what do people think? Tom -- Tom Hughes (tom(a)compton.nu) http://compton.nu/

4 10

Plans for Node.js
by Zuzana Svetlikova 07 Dec '15

07 Dec '15

Are there any actual plans for Node.js stack in fedora? Are we going to update everything and hope that nothing breaks (much)? Is there any way of knowing beforehand if update will break some other packages (because I don't know of any, so please enlighten me)? What about updating v8, nodejs and npm? Are we going for LTS and npm@2 or directly to v5.x and npm@3? I'm sorry for so many questions, I'd just like to have some answers so I know on what I should focus. Thanks

7 38

Thoughts on a NodeJS packaging group
by Jared K. Smith 29 Nov '15

29 Nov '15

Several of the other SIGs have a packaging group with ACL permissions on various packages that correspond with their SIG. I think we're to the point with NodeJS packages that it makes sense to make all of the nodejs-* packages part of a NodeJS packaging group, and then add the main NodeJS packagers to said group. That way, we wouldn't have to request individual ACLs on each of the NodeJS packages should we want to help keep them up to date. Thoughts? Concerns? -- Jared Smith

9 24

How to handle generated code
by Piotr Popieluch 25 Nov '15

25 Nov '15

Some node modules contain generated JavaScript, for example transpiled from es6->es5, generated from coffeescript, or generated with jison. Is it allowed to include these generated files in the module or do we really need to "build from source". The package guidelines do not mention generated code [1] I'm currently reviewing a package [2] which is generated with jison, jison and its dependencies are not packaged. Packaging jison seems like a lot of work without any benefits. What do you think, can we include generated JavaScript or do we have to build from source? Piotr [1] https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-bui… [2] https://bugzilla.redhat.com/show_bug.cgi?id=1232816

5 13

nan v2
by Tom Hughes 23 Nov '15

23 Nov '15

I'm encountering more and more binary modules that need v2.x of nan to build them, and we currently only have 0.x and 1.x available. So I've opened a nodejs-nan1 review: https://bugzilla.redhat.com/show_bug.cgi?id=1284565 Once that is done I will push an update for nodejs-nan to bring it up to v2.x at the same time as I push the nodejs-nan1 module. Tom -- Tom Hughes (tom(a)compton.nu) http://compton.nu/

1 1

Urgent Review Request
by Tom Hughes 21 Nov '15

21 Nov '15

Due a spectacular piece of idiocy on my part I pushed an update to grant that had a new dependency without actually have that dependency available.. So I have review requests open for that dependency now, and for a further dependency of that dependency, and if somebody could manage to review them so I can unbreak rawhide then that would be very much appreciated. The reviews are: 1284180 nodejs-grunt-legacy-log-utils 1284181 nodejs-grunt-legacy-log Thanks, Tom -- Tom Hughes (tom(a)compton.nu) http://compton.nu/

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

nodejs November 2015