Re: Multiple source files

[Andrea Giammarchi <andrea giammarchi gmail com>]

if anyone is interested, without going full NodeJS behavior/core thingy, I've just summarized in a 100% GJS way the `require` utility that works with regular paths without going full rpm resolution.

https://github.com/WebReflection/gjs-require

It's literally 50 LOC and makes GJS imports a joy to work with.

Hope you like it.

Best Regards

On Fri, Nov 9, 2018 at 7:01 PM <makepost firemail cc> wrote:

Very nice program path resolution! I still have to get filenames from
Error stack when inside the imported modules, but for the entry point
your programInvocationName suggestion is definitely preferable, really
clean and doesn't rely on external `realpath` like what I had by now.
Thank you.

On 2018-11-09 19:42, Andrea Giammarchi wrote:
> I've replied directly to him but maybe it's interesting for others
> too.
>
> This is the TL;DR version of how I bootstrap CommonJS equivalent of
> `__dirname` and `__filename` at the entry point level.
>
> #!/usr/bin/env gjs
> const { GLib, Gio } = imports.gi [1];
> const { File } = Gio;
> const PROGRAM_EXE = File.new_for_path(GLib.get_current_dir())
>
> .resolve_relative_path(imports.system.programInvocationName);
> const [
>   __dirname,
>   __filename
> ] = [
>   getProgramDir(PROGRAM_EXE).get_path(),
>   PROGRAM_EXE.get_path()
> ];
> print(__dirname);
> print(__filename);
> function getProgramDir(programFile) {
>   const info = programFile.query_info('standard::',
> Gio.FileQueryInfoFlags.NOFOLLOW_SYMLINKS, null);
>   if (info.get_is_symlink()) {
>     const symlinkFile =
> programFile.get_parent().resolve_relative_path(info.get_symlink_target());
>     return symlinkFile.get_parent();
>   } else {
>     return programFile.get_parent();
>   }
> }
>
> Which gives me an easy way to pollute the import search path as such:
>
> imports.searchPath.push(__dirname);
>
> Now, if inside this very same file, as entry point, you have a folder,
> let's call it `test`, and a `module.js` file inside such folder with
> the following content:
>
> function waitWhat() {
>   print('here I am');
> }
>
> this is how you'd use it from the entry point:
>
> const module = imports.test.module;
> module.waitWhat();
>
> In few words, when you push `imports` you add paths to synchronously
> look for, and anything that leaks in the module scope is exported.
>
> Accordingly, a reasonable patter to export without leaking everything
> per each module is to use an IIFE like:
>
> // var because gjs module system is a bit messed up
> // so if you use const in the module scope it will
> // be exported but it will also trigger warnings
> // once accessed, and same goes for let.
> var {
>   method,
>   util
> } = (() => {'use strict';
>   const method = () => {};
>   let util = () => {};
>   // your export
>   return { method, util };
>   function test() {}
> })();
>
> // if needed
> this.default = method;
>
> As you can see you could even follow the Babel / Webpack pattern of
> exporting `default` (but you need to explicitly import that too).
>
> Good luck with the rest of your project 👋
>
> On Fri, Nov 9, 2018 at 6:37 PM Philip Chimento via _javascript_-list
> <_javascript_-list gnome org> wrote:
>
>> For completeness I should mention that there's of course a built-in
>> way to have multiple source files. To import "foo.js", use "const
>> Foo = imports.foo;", and to import "subdir/bar.js" use "const Bar =
>> imports.subdir.bar;"
>>
>> To set the search path for modules, use "imports.searchPath" which
>> is an array so you can push() or unshift() extra entries onto it.
>>
>> The "imports.package" module simplifies the process of setting up
>> the search path a bit. Unfortunately it's not well documented but
>> you can take a look at how other apps, e.g. gnome-sound-recorder,
>> use it:
>>
> https://gitlab.gnome.org/GNOME/gnome-sound-recorder/blob/master/src/org.gnome.SoundRecorder.in
>>
> https://gitlab.gnome.org/GNOME/gnome-sound-recorder/blob/master/src/main.js
>>
>> Support for ES6 modules and the "import" keyword is in progress,
>> follow along here:
>> https://gitlab.gnome.org/GNOME/gjs/merge_requests/150
>>
>> Best regards,
>> Philip
>>
>> On Fri, Nov 9, 2018, 11:45 , <makepost firemail cc> wrote:
>>
>>> See also https://github.com/makepost/gunit for a test runner, and
>>> https://github.com/sammydre/ts-for-gjs for autocomplete and type
>>> checking. I actually think it's good not to replicate core Node
>>> modules
>>> because we have GLib and other introspected GNOME libs with
>>> language-independent APIs.
>>>
>>> On 2018-11-09 18:22, Andrea Giammarchi via _javascript_-list wrote:
>>>> if you are familiar with CommonJS, I suggest you to use cgjs
>>>>
>>>> https://github.com/cgjs/cgjs#cgjs--
>>>>
>>>> it's not really a 1:1 nodejs replica when it comes to core
>>> modules,
>>>> but at least it doesn't require you to learn a module system
>>> that only
>>>> GJS uses and that will inevitably fade away as soon as ES2015
>>> static,
>>>> or even dynamic import, will be introduced.
>>>>
>>>> Feel free to see the circus around configuring folders and
>>> imports
>>>> otherwise directly via GJS.
>>>>
>>>> On Fri, Nov 9, 2018 at 5:18 PM Tony Houghton <h realh co uk>
>>> wrote:
>>>>
>>>>> gjs has attracted my attention, but the tutorials and examples
>>> are
>>>>> rather simple so I can't work out what you're supposed to do to
>>> make
>>>>> an application with multiple source files. Do you have to write
>>> a
>>>>> script to concatenate them in the right order, or
>>>>> can you use _javascript_'s import keyword?
>>>>>
>>>>> --
>>>>>
>>>>> TH
>> _______________________________________________
>> _javascript_-list mailing list
>> _javascript_-list gnome org
>> https://mail.gnome.org/mailman/listinfo/_javascript_-list
>
>
> Links:
> ------
> [1] http://imports.gi/