Re: Bringing CommonJS and npm to GJS



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.

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.

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]