expose calculateSelectorNode

[bartveneman]

closes #17

• Exposes calculateSelectorNode next to the existing calculate function
• Adds static Specificity.calculateSelectorNode(selector: string) + tests
• Moved around some internals so calculateSelectorNode does not need to reference Specificity each time
• Agree on naming
• Check that /test/standalone is implemented correcty. I suspect the existing tests for calculate don't actually test it's implementation so I did mine a little different than the existing tests. Please double-check my work 😅. Also opened Question: are standalone tests correct? #24 for further discussion.

[bramus]

Apologies for the delay but only now I took a good look into this PR.

One thing I’m wondering is why calculateSelectorNode returns a plain object while calculate does return (an array) with Specificity objects. I would have assumed for both to return Specificity instances

[bartveneman]

~~The existing function already returned a single object, so I simply renamed it and exported it.

It does make sense to me however to keep this method as small as possible, because it's easy to integrate and mock for testing.~~

edit: interpreted your question incorrectly

For my use case I generate sometimes over 10,000 Specificity instances, each with a small enough footprint. Separating instantiating the Specificity object felt light the right thing to do, to keep more of the 'business logic' in the more customer-facing calculate method. On the other hand, I don't have very strong feelings about this, so happy to revert that part.

[bartveneman]

My css-analyzer package has benchmarks enabled in CI and running it with the changes from this MR makes the analyzer 25-50% faster! projectwallace/css-analyzer#423 (comment)

(I don't necessarily trust the benchmarks blindly and ~50% is probably waaaay too much, but I'm very confident that it's faster because it's making a lot fewer function calls and memory allocations)