Let's store the toString'ed value and a dirty bit to know if we can just re-use it.

I know it's a tiny thing, but I think it makes more sense to have conditions follow rather than precede the freetext. I'm happy to submit a PR but would you rather it was an option or a default? Would it be an argument to toString()?

Currently, the library allows for things like cheese and -cheese to be inputted, and doesn't reason about the semantic meaning of having a property and its negation both present. There's also no duplicate checking.

If we were to add duplicate checking, would we want to perform that automatically in an opinionated way? Or should it be user-configured?

How do we want to handle user input vs programmatic input? What kind of errors can we surface to the calling context which can help make the UX feel right?

example of where this has caused issues in the past:
https://github.com/mixmaxhq/app/pull/7505/files#diff-d32a3e6004a682c216ff83320b43464dR234 (private to Mixmaxers)

It would be nice to have a @ types/search-string to include in Typescript projects.

When trying the mentioned functions with quotes, I am confused where I thought the mixed quotes would be preserved after parsing the stringified query. Is the following behavior intended? or I simply misused the functions?

var SearchString = require("search-string")
const str1 = "";
const searchString1 = SearchString.parse(str1);
searchString1.addEntry('from', '\'"\'"', false);
console.log(searchString1.getConditionArray()[0].value) // '\"'\"

const str2 = searchString1.toString();
const searchString2 = SearchString.parse(str2);
console.log(searchString2.getConditionArray()[0].value) // \"\"

In Gmail/Google, a "quoted text" means that it must be included in the search.

getTextSegments() currently gets rid of any extra quotes "". While it's nice that it does that, it'd be cool if it could also mark a flag like mustInclude:true (just like it marks negated for hyphen -)

Great job on this library!

One thing: it seems important to support a whitelist of conditions. What if I wanted to search for text that had colons in it? Let's say a book is called "Foobar: The story of Steve", and a user tries to search for that phrase? You'll currently strip Foobar: out of the text.

Most query DSLs will have a specific set of conditions that are valid. search-query-parser shows their usage here. It would make sense to ignore anything else, imo.

I guess you'd need a breaking change that looked something like this: parse(string, { config })

This will allow for a more convenient way to add multiple multi-word terms. For example:

color:green John Doe, Foo Bar when setting , as field separator.

Solution:
removeKeyword(keywordToRemove, negatedToRemove) { this.textSegments = this.textSegments.filter( ({ value, negated }) => keywordToRemove !== value || negatedToRemove !== negated ); this.isStringDirty = true; }

Foo:bar === foo:bar in most cases I can think of.

Maybe an option {toLowerCase: true} that defaults to true?

#7 (review)

filed here fyi @bradvogel

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (local>mixmaxhq/renovate-config)

Was looking for something exactly like this, and came across a few others:

https://github.com/nepsilon/search-query-parser

Both look equally good at first glance, which makes it difficult to choose... it'd be awesome if there were some comparison between features/goals