-
Notifications
You must be signed in to change notification settings - Fork 289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: expose parser #207
base: master
Are you sure you want to change the base?
feat: expose parser #207
Conversation
Hey Kévin, thanks for your input. I'd appreciate some clarifications about this change. |
I forked VError to be browser compatible, so I replaced
SError throw an error when using a sprintf('%s', null) // throw an error For that it is necessary to parse the tokens before calling sprintf-js. |
Oh, I see. This has been asked before (i.e. supporting relaxed, strict modes) and while I agree to the idea, I'm against such approaches where the (undocumented) internals get exposed. At one point I suggested proxying arguments, but I guess that would only work with named placeholders where you pass an object. |
See also #165 |
I don't see how to check the arguments without using the ast that comes out of the parser, it seems normal to me to export it and document it for more advanced use cases like this. |
It's possible I didn't understand your use case. TBH I don't even know what |
To know if a token is |
What is the inconvenience of exposing the parser? How can I parse the arguments to do some preprocessing before calling sprintf, without duplicating the code of the parser part? |
Probably none, if you do it intentionally. That is not the case with this library. |
This PR exposes the parser as a non-enumerable property.