Closed lsanders closed 5 months ago
Sounds interesting but I'm not sure I understand exactly what you mean. Could you please provide an example?
I'm planning to do something which I think might be similar to what you're suggesting. I was thinking about providing different Expression parsers through library extensions for different expression formats such as the one we have now in jsemver
, maven
and/or node-semver
. So, for example, >=1.0 & <2
and [1.0, 2)
would compile to the identical range.
Thanks for the response Zafar. And for the great library.
Specifically, I want to be able to take a list of components that have node-semver dependency ranges. It looks like your external DSL supports all the common formats. I have a need to convert those to a normalized format - specifically a filter string to be used in an ldap query:
(&(version >= 1.0.0)(!(version >= 2.0.0)))
(which is equivalent to "[1.0.0,2.0.0)" in maven/osgi format)
I'm sure that the ldap query string is pretty ridiculous for most people, but I could see a need to de-sugar to at least a maven like range or an expressive semver string >= 1.0.0 <2.0.0
Expression's internal representation is at least normalized and could then be converted to some other output format, but obviously the internal representation isn't directly usable. And since I'm not a parsing expert, I'm not sure what the best approach to take to get to something like this?
Sorry for the delay Larry and thank you for using jsemver
and taking your time to contribute.
I believe that what you propose is pretty much doable. The good news is that converting one DSL to another should be straightforward provided that we have a parser for the one we're converting from, which we do and you don't have to parse anything on your own. It's not completely node-semver
compliant but as you say it supports the common notations, such as tildes
, carets
, wildcards
, etc. An expression is parsed into AST which is the internal representation of the expression which you can then convert to a required format using the Visitor
design pattern. The bad news is that it wasn't meant for this; the AST classes are package private meaning you can't use them in your code, just not yet.
I'm planning on some changes to the library's structure for the 1.0.0
release namely moving the expression parser stuff to its own package and this will allow you to use the AST directly. In the meantime, you can fork it and adapt to your needs.
I'm not closing this issue as I'm definitely planning to implement this kind of logic.
Hope this helps and let me know if you need any further help.
I'm looking for a way to convert an Expression AST into a query rather than just filtering all the rows on the client.
Closing this issue in favor of #70, the progress can be followed from there.
P.S. To be honest, I'm not sure I'll be able to pull this off, but I'm gonna try.
I realize this is probably outside the original use case for Expressions, but I thought I'd mention it. I'd really like to use this library to normalize the various version range formats. Any thoughts on that? Thanks.