'+' gets turned into a space

[jdcc]

For example:

> const norm = require('normalize-url');
> norm('https://www.google.com/search?q=a+number+of+boring+things');
'https://google.com/search?q=a number of boring things'

Not sure what you want to do with this, but it tends to confuse parsers.

[kevinsearle]

Looks like this is a result of query-string #33:

urlObj.search:
?bar=foo+bar
queryString.parse(urlObj.search):
{ bar: 'foo bar' }

[sindresorhus]

See: sindresorhus/query-string#33 (comment)

@jdcc If you want to use it somewhere where it needs to be parsed, you need to escape it again:

encodeURI('https://google.com/search?q=a number of boring things')
//=> 'https://google.com/search?q=a%20number%20of%20boring%20things'

[soulne4ny]

Does it mean %20 is turned into space too?

[jdcc]

Not to my knowledge, no.

@sindresorhus Sorry, I didn't see your last comment until just now. I understand outputting spaces in a query string parser, but why not encode them in this package? The normalization process as it stands is effectively turning a valid URL into an invalid URL.

[soulne4ny]

Let's consider an url with + for spaces and true + encoded with %2b. Then once any '+' is replaced with a space, the url is effectively broken, not normalized as it should be. The worse side-effect is that it can't be fed to url-encode, because %2b should stay as it is. That is really bad approach.

No one expects a function that should normalize a value actually to behave the other way around, breaking it. No one expects that it is essential to look through all closed issues before considering the library useful. No one expects that it is essential to make own tests with 100% coverage for all the libraries added to a project.

It is not a complaint. It is just statement that unexpected behaviour causes unexpected side-effects and therefore problems to the library users.

And this case is at least a subject for a new test case showing that it breaks some values instead of normalizing them.