GNOME.org
 

Re: Bringing CommonJS and npm to GJS

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 giammarchi 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 chimento gmail com> wrote:


On Fri, Nov 3, 2017 at 3:16 PM Andrea Giammarchi
<andrea giammarchi 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 giovanni 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 giammarchi 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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]