Moved to type-flag repo since it's type-flag that handles -- parsing.

Thanks for requesting this feature. I needed something similar in git-detect-case-change but I was able to work around it so it wasn't strong enough of a use-case to warrant -- separation.

I think the use-case you described, including scripts like npm run foo -- bar, support the need for this functionality.

This will be a breaking change but I'm happy to make it.

I'm thinking about creating a .__ property to access arguments after --.

However, it might be confusing to discern between ._ and .__. Minimist uses the ['--'] property, but I don't really want to force users to use the computed property syntax just for this.

Do you have any other ideas?

I think the use-case you described, including scripts like npm run foo -- bar, support the need for this functionality.

That's very close to the case I had in mind.

This will be a breaking change but I'm happy to make it.

This wouldn't need to be a breaking change if you continued appending the extra args to _ but also to a separate array. That's kind of what I had in mind originally.

However, it might be confusing to discern between ._ and .__. Minimist uses the ['--'] property, but I don't really want to force users to use the computed property syntax just for this.

Do you have any other ideas?

Very good points. Maybe .extraArgs or .unknownArgs?

Alternately, it could be a well-known property attached to _, similar to parameter names? Something like _.extraArgs? This would cause a conflict if someone added a parameter named extraArgs, but this issue already kind of exists with length (conflict between a parameter named "length" and the Array property).

Another option to all of this would be:

• Expose args property that contains all known arguments (similar to flags)
• Expose unknownArgs property that contains anything passed after -- (similar to unknownFlags)
• Keep _ as-is

Thank you for the feedback! It was very helpful.

I think I have decided to move forward with _['--'] because:

• Using a word (eg. extraArgs) as a property on ._ would collide with parameters in Cleye. Good point about length and any other Array prototype methods though, but those are much more predictable as they're standard JS.
• _['--'] is verbose but also more explicit and clear than trying to make a new term to describe it. I think this is especially important to contributors trying to read the code of a project that uses Cleye/type-flag

I plan on testing it in some of my projects tomorrow before I release it but feel free to give it a try if you'd like and share feedback:

• If you're using type-flag: npm i 'privatenumber/type-flag#built/end-of-args-property'
• If you're using cleye: npm i 'privatenumber/cleye#built/end-of-args-property'

Awesome! Thanks for being so receptive to ideas. I’ll give it a try soon

Available in v2.1.0! Releasing in Cleye soon.

Thanks @jgoz

Released in Cleye 1.1.0