Re: Bringing CommonJS and npm to GJS

[Andrea Giammarchi <andrea giammarchi gmail com>]

People are distributing Desktop applications via Electron, which also needs double modules when it's native and as of today, we do need to say to developers that GJS cannot consume npm modules.

Differently, from Gtk, The GNOME SDK is confined into the Linux world ... or at least that's my impression after a tour in the documentation where windows binaries are from 2014 and others are called older MacOSX binaries.

If you keep GJS confined in Linux, and outside npm, you'll have very low interest in adoption/contributions.

The fact we've tried alredy to have Gtk in NodeJS many times should be a strong signal on what the community wants.

Node is well documented and widely used in production, yet the access to npm is what makes NodeJS the desired environment many use daily.

I know that there is effort to bring React native devlopment via a re-vamped node-gir project and that is agan Gtk in node, but when you have FB people behind that usually works thanks to marketing and the thousand of engineers.

Yet, I like GJS and I've posted about it and put quite some effort to make it better and I am enthusiasm about helping out yet all I receive is some FUD about npm bringing overhead as if it does it by default?

You can also package via asbundle in GJS because I write tools compatible with GJS and with GJS and other platform in mind so my apologies if when I read that npm is bad I go a bit defensive but GJS is niche right now and I am not sure why would anyone want to keep it like that.

Regards

On Wed, Nov 8, 2017 at 3:38 AM, <philip chimento gmail com> wrote:

On Sun, Nov 5, 2017 at 4:30 PM Andrea Giammarchi <andrea giammarchi gmail com> wrote:

npm is just a repository.

A repository exists in Python, Ruby, ArchLinux (AUR), Debian, etcetera.

A repository purpose is to publish a program/module/library  that can be reused across projects.

A repository doesn't force you to create dependencies.

A repository doesn't need your code to be compatible with everything else.

A repository is a place to publish and consume common reusable code.

In GJS everyone is re-inventing the wheel daily.

I've seen GJS examples repository and laughed hard at the dance to obtain the current working directory:

https://github.com/optimisme/gjs-examples/blob/master/egAsset.js#L17-L30

Instead, someone (like me) could write a module that does the proper dance to grab most essential info on bootstrap so that everyone else could `const info = require("gjs-app-info")` and use `info.program` instead of that old hack.

Same goes for 3rd parts modules that are not bound to Node or Browsers (or Nashorn or Espruino ... or ... )

Accordingly, having the ability to use a central registry to share code worked for everyone in the JS community, keeping GJS outside that is a huge missed opportunity.

This, of course, unless I realize there is a parallel universe full of community effort to make GJS easy for newcomers.

That's a bit over the top Andrea - of course there isn't. I appreciate your efforts and I'm happy you're contributing this, as it's something I've wanted to do for a long time. We may not have enough contributors to move things as fast as anyone would like, but please help to maintain a supportive and positive environment on the mailing list. That will encourage the contributors we have to stay around.

So far, unfortunately, I haven't seen that place though, hence my effort.

Regards

On Sun, Nov 5, 2017 at 4:49 PM, Luke Jones <luke nukem jones gmail com> wrote:

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.

My opinion: I'm not fond of the way npm does packages and I think it's more suited to a workflow where you bundle everything up with webpack. That said, I heavily encourage the use of flatpak and the GNOME SDK to write apps with GJS. That makes packaging into the app author's responsibility, so we don't need to say what app authors can and can't do from a GNOME point of view. Hopefully this will encourage people to write apps using whatever tools and technologies they're comfortable with.

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

Regards,

Philip C