One of the issues I have with NPM support, is that then brings the undesirable hundreds of package dependencies through encouraging the use of them. If someone *does* use NPM packages and creates an app with this support, then that introduces some seriously big headaches with packaging for distros.
Unless I'm missing something? The way I see GJS is JS for GNOME. Not as a universal JS runner, and so doesn't need NPM or anything as complex as that. On 6 November 2017 at 07:34, Andrea Giammarchi <andrea.giammar...@gmail.com> wrote: > If until now GJS ignored the rest of the world in terms of JS modules and > the ability to use npm as registry, I believe I'm not the one that can > answer that question but I am 100% sure if you want GJS to be more popular, > you need a better JS ecosystem integration, and npm is mandatory step zero > to obtain that. > > However, until CGJS is under development, I don't see GJS integrating it > unless you mean just the basic `require` mechanism for which I am sure it'd > be super useful to have it in core so that I just develop dependencies and > forget about the thin GJS wrap. > > Having `require` but no modules though might mislead new comers so maybe, > once again, until CGJS is fairly usable and stable and it covers more NodeJS > core functionalities, we can think about how integrate it and ship it via > GJS. > > Not sure I've answered your question though. > > Regards > > > On Sun, Nov 5, 2017 at 3:07 PM, <philip.chime...@gmail.com> wrote: >> >> On Fri, Nov 3, 2017 at 3:16 PM Andrea Giammarchi >> <andrea.giammar...@gmail.com> wrote: >>> >>> yeah, that's why I need help/contributors there. >>> >>> The fs is relatively trivial, streams are more painful but in JSGtk the >>> fs was already working. >>> >>> I am just starting porting over and improving JSGtk, today you have >>> already console globally available, util in core (and timers) and I'm >>> working on os, needed by process, and streams soon, also needed by process, >>> together with EventEmitter ... I will use as much code from Node as I can >>> though, right now the focus is on the architecture to make core modules easy >>> to develop, test and deploy, which I think it's the case already. >>> >>> The last thing I've done a part is the utilities repo which has a GJS >>> based query object for the whole env >>> This file might be useful regardless: >>> https://github.com/cgjs/utilities/blob/master/about >>> >>> If you'd like to help moving forward just let me know and I'll add you as >>> contributor. >>> >>> There's also some basic guidelines on how to: >>> https://github.com/cgjs/cgjs/blob/master/CONTRIBUTING.md >>> >>> Regards >>> >>> >>> On Fri, Nov 3, 2017 at 6:44 PM, Giovanni Campagna >>> <scampa.giova...@gmail.com> wrote: >>>> >>>> On Thu, 2017-11-02 at 22:50 -0300, Andrea Giammarchi wrote: >>>> > FYI the whole project has been moved under a CGJS organization: >>>> > https://github.com/cgjs/cgjs >>>> > >>>> > If you'd like to contribute please rise your hand and I'll add you. >>>> > >>>> > So far working: >>>> > require, console, __filename, __dirname, and all timers in place >>>> > next up: process module >>>> > Each core module can be developed a part, using the old jsgtk source >>>> > code to take some example makes it relatively straight forward to >>>> > implement what was there already (hopefully cleaned thanks to modern >>>> > JS syntax). >>>> > >>>> > Modules are many but not all of them would be essential to make GJS a >>>> > NodeJS developer friendly environment or to share npm modules. >>>> > >>>> > Here the modules TODO list that is worth prioritizing somehow. >>>> > https://github.com/cgjs/cgjs#commonjs-modules >>>> > >>>> > I still would like to hear some feedback, thank you! >>>> >>>> >>>> Not sure what feedback you're looking for here, but I'd say the project >>>> seems really useful, and I hope it succeeds. >>>> Right now writing a desktop app in JS has to either choose node (losing >>>> all the good stuff in the Gtk+ platform) or gjs (loosing all the npm >>>> libraries), which is sad. >>>> With this, most JS only (or browserify-ready) node modules will work. >>>> >>>> This said, it looks like you have a long way to go to fill the fill of >>>> core node APIs as cgjs modules. >>>> For some module, it might be worth just copying the node source, once >>>> you have a few base APIs. At least "assert", "events", "stream", >>>> "querystring", "url", "util", maybe even "module", given you have a >>>> working require(). >>>> That should give you a lot more support for npm modules out there. >>>> >>>> (browserify also has some support for those I believe, and might be a >>>> better source than node, not sure). >>>> >>>> The biggest obstacles will be "net", "http" and "fs", which any >>>> nontrivial node module will want to use. >>>> >>>> Good luck! >>>> >>>> Giovanni >>>> >>>> > On Thu, Nov 2, 2017 at 1:17 PM, Andrea Giammarchi >>>> > <andrea.giammar...@gmail.com> wrote: >>>> > > I've been thinking about for a while and finally made up my mind: >>>> > > JSGtk+ was solving the wrong issue and in a wrong way. The project >>>> > > is officially death/deprecated now, but not without an alternative >>>> > > ... bear with me ... >>>> > > >>>> > > npm is the biggest Open Source repository of them all. It's not >>>> > > about NodeJS code, it actually has more Browser modules than Node, >>>> > > but it also has Espruino, Nashorn, MS ChackraCore ... you name it. >>>> > > >>>> > > Having GJS out of npm is the number one issue I have, while having >>>> > > also a 100% NodeJS compatible API is less relevant. >>>> > > >>>> > > This is why I've created an alternative to JSGtk+ called CGJS >>>> > > (CommonJS based GJS), which can be installed via npm install -g >>>> > > cgjs and can be used already to require, in a CommonJS fashio, >>>> > > scripts and modules from your project folder. >>>> > > >>>> > > More details here, and I'd love your contribution / feedback. >>>> > > >>>> > > Thank You! >> >> >> Yes, this looks pretty useful. Do you think it would make sense to >> integrate it into GJS in the future and if so, what form do you see that >> taking? >> >> Regards, >> Philip C > > > > _______________________________________________ > javascript-list mailing list > javascript-list@gnome.org > https://mail.gnome.org/mailman/listinfo/javascript-list > _______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
