Orgaizing Util Functions

[Ore4444]

One-file with all utils? One-file per util function? Files representing groups of utils?
Which approach should be picked for Vorpal?
We had a discussion over Slack, trying to summarize so we can continue here.

a grouping example

regroup the prettying utils as formatting (pad, padRow, prettifyArray)
and eventually to regroup the commands utils and the args utils together

some potential downsides of one-file per util

more files to ship, more files to require, and a new helper needed needs a new file.
more difficult to maintain.
It really depends when you put the cursor, a 1k line file is indeed to much, too many little related files is also too much
having reasonable amounts of files avoid dispersion, reduce need for file navigation, (not to speak of adding a new file everytimes you need a new helper (which might also need existing helpers)

some potential downsides of grouping

more files can be better, when it comes to standalone utilities. makes it easier to maintain because when you look at a utility you see only that one without noise around. also, it makes the structure of utils the most flexible e.g. maybe some parts of a code need them all as one flat object, so we can create a barrel. maybe some other parts need a specific grouping of 3 utils, so we compose an object of utils for that purpose

a lot of libraries ship a lot of files and the number of files itself does not hurt the ability to ship. large number of files also means more explicit dependencies between the files, which is generally better.

@hongaar :

In my experience (mainly with large React TS apps) having one external export per file works best (both for components and utilities): it improves discoverability and testability (with mocking etc.). It's also how well established libraries like lodash (!) and Material UI etc. are doing it. We also only use named exports (using the same name as the module a.k.a. filename). Then we create an index file per directory, exporting all submodules with export * from './submodule . This way, you never have to deeplink into a directory (which we enforce with https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-internal-modules.md). Using named exports makes it impossible to use arbitrary names for modules, further improving discoverability. (edited)
When we need some form of grouping (common with React components, not very useful for utility functions) we use function properties for convenience like so:

import Group from './Group'
export const Radio = (props) => ...
Radio.Group = Group

about VorpalUtils

ie exposing utils for developer consuming the lib by building cli,
we should preserve it:
but if we do so we should split internal core helpers (for us) and real vorpalUtils for our user
cf https://github.com/vorpaljs-reforged/vorpal/pull/31/files#diff-de19b2134d2337439559505d0ce0d3a5L19
Probably no need to give access to parseCommand, matchCommand and else.