Leading wildcards don't work

[floatingLomas]

*.foo.com does not match foo.com; however, I can get it to do so by reversing both strings.

Is this expected behaviour?

[DamonOehlman]

I think this should be made to work, so I'll try and get time to implement it sometime soon. PR's are also gratefully accepted :)

[bradennapier]

This is pretty old - but just wanted to note that *.foo.com would match .foo.com -- perhaps you wanted *foo.com ?

[revelt]

Regarding @floatingLomas question, your example is wrong because the leading full stop, the first character, is missing in foo.com. However, your accusation is legit! Here's a better, correct example:

var wildcard = require("wildcard")
var res = wildcard('*foo', 'foo')
console.log('res = ' + res)
// -> "res = false"

The res should be true. This drives me mad, there's another library, wildstring which has this very same issue and was driving me mad so much that I came looking for alternative, but this library misbehaves too!

According to Wikipedia:

"In software, a wildcard character is a single character, such as an asterisk (*), used to represent a number of characters or an empty string" (emphasis mine, RR).
— https://en.wikipedia.org/wiki/Wildcard_character

What means, this library is incorrect conceptually, treating wildcard character as at least one character instead of zero or more characters.

You see?

Try running this on RunKit.

We need a new wildcard library with a correct algorithm (or this one fixed).

[bradennapier]

https://github.com/Dash-OS/redux-saga-process/blob/master/src/lib/wildcard.js

I largely re-created wildcard in the redux-saga-process code provided @revelt might find something useful

[revelt]

@bradennapier dude you should publish it as a standalone lib on npm! Will check it out right now. I prefer standalone libraries from npm because they're self-contained, with unit tests and API documentation. I can help you to publish it and add you to maintainers if you want. What do you think?

[bradennapier]

Considered it, not 100% sure what I even did there honestly - redux-saga-process is a npm library but obviously the wildcard is not. It's meant to take an object with wildcards and filter it for redux patterns.

static actionRoutes = {
    '*Probe': 'probe'
};

[bradennapier]

@revelt One of the main issues I had is most of them were requiring node whereas I needed it to work in the browser.

[bradennapier]

https://github.com/Dash-OS/redux-saga-process/blob/master/src/lib/reducerGenerators.js#L30-L41

You can see it being used there

[revelt]

Thank you. That's quite an advanced level of JS by the way. I'm thinking how I'd write this from scratch, with bunch for loops, if's and inner state flag variables.

[revelt]

Notes for posterity no.1.

I switched to another library to match strings with wildcards, matcher. It does the job well and supports the leading wildcards out of the box.

Notes for posterity no.2.

Another string wildcard library, wildstring also has this very same issue with leading wildcards, so don't waste your time with it either. Stick with matcher.

[bradennapier]

@revelt heh yeah I like to try to write things as efficient as possible. It's EXTREMELY performant when you run it. Would be interesting to test it against matcher. Looks like a simple enough library and a good choice overall though.

[DamonOehlman]

Apologies for letting this one slip folks. I'll add a note that people should definitely consider using matcher if they have come across this library. Additionally, add a test case that demonstrates this breaking case and fix it as I agree with @revelt it is definitely a violation of the expected behaviour of * in all expected instances.

[DamonOehlman]

Fixed by #11 - also added a note to the README directing people to matcher as it's definitely better maintained...