Command line support via Commander.js

[KaruroChori]

I hacked the popular commander.js to work with txiki.
The implementation of the "adapter" I made is awful, but it works enough to run all the demos I tested.
https://github.com/KaruroChori/commander.js/tree/txiki

The main "issue" is that all the operations in txiki are async, while this library uses sync functions for virtually everything.
I left out some stuff like stdXXX.write, and there are few calls which should be implemented native in txiki like checking for files to exists. I will open issues to cover those.

[KaruroChori]

I added support of it as an external module for #524 (in dist/ via an automatic script)
It works! I just need to add an action to generate the tar.gz as an artifact on releases.

[saghul]

Cool!

The main "issue" is that all the operations in txiki are async, while this library uses sync functions for virtually everything.

Addind sync functions is a hard no from me. It's 2024 and we have top-level await!

like checking for files to exists. I will open issues to cover those.

Please open whichever APIs are missing, but that one is there already, just do a stat on the file.

[KaruroChori]

I agree, it is just that the widest majority of legacy code is still based on that mess of sync calls which node used forever.
So porting code over is just not as easy.
Ideally it should just be refactored as I did to make it use modules.

Please open whichever APIs are missing, but that one is there already, just do a stat on the file.

I missed that one!

[saghul]

I understand, but supporting Node APIs is not a goal I have for txiki.js.

[KaruroChori]

I totally agree with you, I am not making a case against the direction you have for the project.
It was just leaving some reference & report of my struggles for those which might want to port things over in the future :D.

[saghul]

👍

[Tobbe]

It's really great to see all the work you're doing here @KaruroChori!
We chose to use yargs instead of commander for our CLI for RedwoodJS. (And we're also big fans of zx, as I saw you also wanted to make a module for!)

Just to better help me understand what I'm up against here I have a couple of questions

1. Why did you chose to try to add commander as a module instead of just using what txiki.js already has to do what you need? What are the main pain points you see commander solving for you compared to just writing it on your own?
2. How difficult would it be to also make yargs be a module for txiki.js?

[KaruroChori]

Why did you chose to try to add commander as a module instead of just using what txiki.js already has to do what you need?

Two reasons:

• While I have been using yargs in the past, for most of my recent projects I went with commander instead. So the answer is one part habit.
• commander, while not strictly against having dependencies in their code, has none except for some native node stuff. yargs is not standalone, which makes the process of fixing all the potential upstream problems and bundling it in a single module much more complex.

What are the main pain points you see commander solving for you compared to just writing it on your own?

Being able to port a lot of CLI code I wrote without major refactoring needed. The biggest issue was changing all that synchronous code in commander to be asynchronous as requried by txiki, which might have introduced several undetected bugs. Also the interface to bridge node with txiki is not perfect, so there are surely edge cases not covered.
An implementation from scratch of a similar library for txiki would not be a bad idea, assuming one can allocate enough time for that.

How difficult would it be to also make yargs be a module for txiki.js?

Possibly a lot, because of the issues mentioned before. But I have not fully investigated its dependency tree and the interface of node modules it uses, so it might be surprisingly more simple.

[Tobbe]

Being able to port a lot of CLI code I wrote without major refactoring needed.

That would be the reason I'd implement yargs as a module too.

But on the other hand I kind of want to just write something super tiny and simple without so many dependencies at first. So I'll probably see just how far I can get with just the txiki built-ins before I start trying to make yargs work.

Just need tjs compile to be implemented first 😄

[KaruroChori]

The proposal for modules as discussed in the first message of this discussion has evolved into #524, https://github.com/KaruroChori/txiki-modules & a few external modules which have been either ported or implemented from scratch.
All I can say is that modules work and all features I considered to be mandatory in a first implementation have been done. I am using them and I am happy, but I am also their author so there is some bias there :D.

Still, this module proposal has not been reviewed by Saghul yet.
So, in theory, all the code I wrote to support external modules might never be integrated to mainline txiki.

You can technically write your own custom modules inside txiki without my implemented proposal (which I did, at the very beginning for the first implementation of commander), however the reason I implemented it is to also work around the limitations of the txiki build model (like those you observed). Basically, if you implement a module based on my proposal, you should not have issues with the tjs compile as all the bundling is already done upstream within the external module repository, and the rest of the process is fully automatic as well.

https://github.com/KaruroChori/demo-txiki-module shows how a demo external module would be implemented under my proposal.