Consider using ECMAScript modules?

[nagy]

Hello,

I just wanted to ask if this project considers switching to ECMAScript modules in the future. This would allow other Javascript implementations like Deno to run this code as well.

So basically, instead of using things like require('fs') you would use import 'fs'.

Node has had stable support for esm since version 14.

Links:

• Node ECMAScript latest docs: https://nodejs.org/docs/latest/api/esm.html
• Deno Homepage: https://deno.land/

[acrisci]

I don't think that will be enough to make this library support Deno. I rely on a lot of OS functionality of Node which will be different with Deno. Right now I support a very low version of Node, v6, which I consider to be a good feature of the library. I'd need more justification than possible Deno support to use the new modules. If you're considering doing a Deno dbus project, let me know because I may be interested in contributing to that in some way.

[nagy]

I don't think that will be enough to make this library support Deno. I rely on a lot of OS functionality of Node which will be different with Deno.

I would think that something like compatibility helpers would be required, but Deno is capable of reading files and opening TCP and UNIX connections. There is also a way of dynamically calling imports to help write this helper, which could end up being just a plain JS Object so we would not need fixed import statements.

Deno connect api: https://doc.deno.land/deno/stable/~/Deno.connect
MDN dynamic imports: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#dynamic_imports

Right now I support a very low version of Node, v6, which I consider to be a good feature of the library.

Keep in mind, that the support for Node v6 has ended in April of 2019.

NodeJS Current release plan: https://nodejs.org/en/about/releases/
Wikipedia on NodeJS releases: https://en.wikipedia.org/wiki/Nodejs#Releases

I'd need more justification than possible Deno support to use the new modules.

Apart from Deno support, the conversion from Node specific code to standardized Javascript code has another benefit. A DBUS could be made accessible to Webpages and Webextensions. The connection can be established via Websockets but this would require a proxy server installed locally of course. This could allow webpages to communicate with other programs running locally and vice versa and this was my main interest point for this question.

There is also a lesser known Javascript engine from Fabrice Bellard called QuickJS. It is embeddable into other programs.

QuickJS Homepage: https://bellard.org/quickjs/

If you're considering doing a Deno dbus project, let me know because I may be interested in contributing to that in some way.

I would not start a new project for this since it is too much work, but I am willing to contribute help here.

[acrisci]

I would think that something like compatibility helpers would be required, but Deno is capable of reading files and opening TCP and UNIX connections.

If complete Deno support is possible, I would consider dropping support for older versions of Node and moving in that direction. I don't know how complete Deno's OS support is at this time. I need some advanced features of Unix such as connection to abstract sockets. It looks like v12 will be EOL in a few months so I would be more comfortable supporting only >=v14 at that time.

I am willing to contribute help here.

If you'd like to start making a specific plan to do this work, I would likely accept it in the project because this is a feature I'm interested in. If it's possible to support v12 that would be best. Keep me updated on your findings and I'll help you out with the design and implementation plan.

[nagy]

I am fairly sure you can listen on abstract sockets with something like this:

let listener = Deno.listen({path: "\0mysocket", transport: "unix"});

because abstract sockets are normal unix sockets who's name start with a zero byte.

Is there any other feature you need that is considered advanced?

[nagy]

I have started with this implementation in this branch https://github.com/nagy/node-dbus-next/tree/esm .

My plan would be ( as it seems that this is the only way possible ) to convert from the outside to the inside. Meaning that I first started to convert index.js and at the end would convert the (leaf-)files, that do not have any dependencies.

In that branch, there is currently a rename from index.js to index.mjs , but in the final version this is not needed because we can add type: "module" into package.json. Then we can continue to use the .js extension as if they were ES Modules.

[nagy]

Does this go in the right direction for you?