Use a dynamically assigned require function so that Clime can be used with Webpack

[booninite]

First, absolutely awesome library. It is everything I've ever wanted from a CLI framework after working with commander.js and oclif extensively.

I'm using your module with webpack, and the statements such as:

require(path);
require(possiblePath);

cause this package to break with webpack. I've successfully made it work locally by providing the following export from your internal-util directory:

// @ts-ignore
export const requireFoolWebpack = typeof __webpack_require__ === 'function' ? __non_webpack_require__ : require;

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.

[vilicvane]

Hi, love to hear that you enjoy this library. Can you tell a little bit more on the scenario using webpack but not packing those command files?

It would be nice for Clime to support webpack, but why would people use webpack for dynamically loaded commands that are not going to be packed?

[booninite]

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.

[vilicvane]

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.