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 <makep...@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 , <makep...@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/ >
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
