should core/parser be exported?

[jameyg42]

Somewhat under the "Everything is Customizable" feature, prior to v4 the core/parser module could be used/customized standalone. Since v4 this is no longer possible since core/parser (and core/interfaces/parser.js) is not exported.

One example use case is the use of Parser.parse() without calling validate() to allow for "unrecognized flags" similar to how strict=false allows for unrecognized args.

A specific example is if an oclif command is simply wrapping another command and we want to pass the wrapped command its arguments w/out having to understand them. This could previously be accomplished by using Parser.parse() as-is, treating any detected "nonexistent flag" simply as "unrecognized", then calling validate() w/ an empty nonexistent-flags array. While -- would work, it ends up defeating the illusion that we're "extending" another (non-oclif) command.

could/should core/parser be exported?

[mdonnalley]

Sorry for the oversight. I can make a PR to add parser to the exports

#1098

[jameyg42]

It might be more than this (#1098). For example, right now we can't easily override something like core/Command.parse() because all of the types are in the unexported core/interfaces/parser. But i realize what I'm probably asking for (which likely makes it too large of an ask) would probably be closer to exporting core/interfaces/.js and core/parser/.js

[mdonnalley]

Sorry, I didn't read through your original post more closely - too much multitasking today! I'll reopen the discussion

I think we stopped exporting those types because it made it difficult to improve the type safety of flags without introducing breaking changes for anyone who might be using importing types. I'm open to exporting them again though since that part of the code base has stabilized over the past year or so

[mdonnalley]

I exported all the relevant types in #1099

Feel free to make a new issue or PR to add anything else you need