`originalPositionFor(generatedPosition)` fails on string positions

[fresheneesz]

I was sending in strings instead of numbers to the originalPositionFor function. This works unless the strings aren't exactly in the mappings. E.g. originalPositionFor({line:"8", column:"10"}) would work if the sourcemap contained that exact entry, but if it instead contained line 8, column 8 and line 8 column 12, it wouldn't find the sourcemap.

Please mention that line and column MUST be number (not strings) in the readme documentation.

[lydell]

Do you mean that you accidentally sent strings instead of numbers to the originalPositionFor() method, and that works sometimes, which gave you a hard time debugging, and that improved documentation would help others from doing the same mistake? (#101)

The documentation currently says:

The only argument is an object with the following properties:

• line: The line number in the generated source.
• column: The column number in the generated source.

That sounds a lot like numbers to me. What do you suggest?

[fresheneesz]

That's exactly what I mean, yes. What would be most helpful (debugging wise) is to throw an exception if someone passes in a string. If you think that's too heavy weight a solution, I'd suggest throwing in "line number (not a string)" to the docs.

[mattflix]

This entire issue could also be "fixed" if the library used coercive (==) equality checking instead of strict (===) when comparing generatedLine values in originalPositionFor(). AFAICS, this is the only thing stopping the function from working when string values are passed instead of number values.

Rather than be a stickler for completely correct but arguably ambiguous documentation ("Our docs used the word 'number', so obviously we meant only Javascript number values, not string values containing numbers like some nincompoops try to pass to our library"), the library could simply be made to be forgiving about the input format. Meaning, a number, or a string representation of the same number, could both be accepted and produce the same result. In this case, it would seem that a single character code change (to the equality check) would make that possible.

---

Btw, although seems to have been nearly four years since this issue was originally filed, I only recently got tripped up by it too... I "innocently" had parsed the line and column numbers out of a stack trace, and passed the resulting strings directly to the library (seemingly a very common pattern for users of this library). Instead of just working and delighting the user, I (the user) had to spend time debugging what was wrong. As @fresheneesz suggests, a helpful diagnostic would have saved me this time, as would possibly a clarifying note in the documentation. Or, as I suggest, the library could have simply accepted my string values in the first place.

[vince1995]

I stucked into this for nearly a half hour. A common errors section in the docs would be really helpful.