You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not against packing those files, but I found it straight-forward to have each command as an entry field on the webpack configuration, and then configuring output to ensure that each entry chunk is output in the same tree structure as the source for my CLI. I also intend on allowing users to install other clime based CLI as "plugins", which I think precludes bundling the different commands.
I was also considering initial bundle load size for large CLIs. I'd be interested in your thoughts on all of the above, though. These have just been my explorations in trying to provide a plugin-based CLI without using oclif.
I see. Actually one of the reasons that clime chose to have dynamically loaded commands is large CLI tools. I think exposing a configurable require function would be enough in this case, and it does look convenient to me considering not being a big addition.
Currently we have some configurable options related to module resolving on the constructor, such as commandModuleDefaultName, I think we can add a commandModuleRequire in this case.
First, absolutely awesome library. It is everything I've ever wanted from a CLI framework after working with
commander.js
andoclif
extensively.I'm using your module with webpack, and the statements such as:
cause this package to break with webpack. I've successfully made it work locally by providing the following export from your internal-util directory:
This allows the require statements to work correctly in webpack and non-webpack environments/bundles.
Would you be open to using something like this in place of
require
?Cheers.
The text was updated successfully, but these errors were encountered: