Thoughts on offloading some string methods to lodash modules.

[jdalton]

As y'all know Lo-Dash v3 is adding 17 string methods, also available as individual npm packages:

_.camelCase, _.capitalize, _.deburr, _.endsWith, _.escapeRegExp, _.kebabCase, _.pad,
_.padLeft, _.padRight, _.repeat, _.snakeCase, _.startsWith, _.trim, _.trimLeft, _.trimRight,
_.trunc, & _.words

With that brings the opportunity for underscore.string to offload to those packages instead of maintaining duplicate implementations. Thoughts, opinions?

[stoeffel]

I don't think we will offload our implementations to Lo-Dash since underscore.string will be a fully standalone library in version 3.0 (#359) and as such should implement all relevant methods.

[jdalton]

I think it's a bummer that we each maintain implementations of the same methods. Underscore.string's implementation of startsWith and endsWith is already based on Lo-Dash's. Offloading would be a win for devs as like-methods would align, would be a win for y'all as it would reduce your maintenance cost, & you'd get the benefit of more eyes on methods.

Offloading to Lo-Dash modules wouldn't mean you'd have to include Lo-Dash in a page to run Underscore.string. The relevant modules would be bundled & compiled in like other Underscore.string modules. For external API you could even have things like ./capitalize.js be module.exports = require('lodash.capitalize') or module.exports = require('lodash/string/capitalize') so it would be seamless to the user.

[stoeffel]

I think it's a bummer that we each maintain implementations of the same methods.

I think so too, but there are already a lot of modules out there which maintain implementations of the same methods.

• https://www.npmjs.com/package/camelcase
• https://www.npmjs.com/package/string
• https://www.npmjs.com/package/repeat-string
• ...

Offloading would be a win for devs as like-methods would align

Yes that's true.

The relevant modules would be bundled & compiled in like other Underscore.string modules

The problem with that is, that we would get issues related to methods we don't maintain ourselves. Underscore.string would be split in two parts.

[jdalton]

I think so too, but there are already a lot of modules out there which maintain implementations of the same methods.

Each by different authors, with different styles, & different support. A nice thing about offloading to Lo-Dash for these methods is support and behavior is uniform. Lo-Dash makes up 3% of npms monthly traffic & is depended on by thousands of devs which means more eyes & more opportunity for fixes and optimizations.

The problem with that is, that we would get issues related to methods we don't maintain ourselves.

That's fine, just point them to the right direction. You could even document the methods that are offloaded for clarity. Closing an issue an redirecting requires minimal effort.

Underscore.string would be split in two parts.

It's modular it's split into many parts :P

[stoeffel]

My main problem with offloading is that underscore.string would, as you implement more string functions, become more and more just a wrapper for Lo-Dash's string functions.

What do you think @epeli?

[jdalton]

My main problem with offloading is that underscore.string would, as you implement more string functions, become more and more just a wrapper for Lo-Dash's string functions.

I'm sure there'll be things Underscore.string will want that Lo-Dash won't. There'd still be room to expand and make things your own while using Lo-Dash for common ground modules.

[esamattis]

Not totally against this. Feels bit weird thou. We would lose some control over the library in that case. What if we want to modify a method in such way that the developers of Lo-Dash do not agree with? And even if we agree there's some extra bureaucracy when fixing it. Also I think it can be bit confusing for the users. In the end these are so small functions that the benefit of off loading is not that big imo. But lets keep this issue still open.

just a wrapper for Lo-Dash's string functions

Does not make this obsolete. The great benefit of Underscore.string, Lo-Dash and other kitchen sink libraries over some individual modules on npm is that you know that they have seen some real world action and that they have been build and/or vetted by developers you trust. They also make them easier to discover.

[stoeffel]

In the end these are so small functions that the benefit of off loading is not that big

I think so too. However it would be nice, if we bump each other if someone gets an issue that the other may also have.

[jdalton]

@epeli

What if we want to modify a method in such way that the developers of Lo-Dash do not agree with?

Then wrap or drop the module. There's nothing locking Underscore.string in.

Also I think it can be bit confusing for the users.

I think devs should be able to understand modules & dependencies easily enough.

In the end these are so small functions that the benefit of off loading is not that big imo.

Small functions but lots of places for things to go wonky like escaping unnecessary characters in escapeRegExp, missing whitespace in trim, missing ticks in escapHTML, not handling accents as correctly, etc.

The great benefit of Underscore.string, Lo-Dash and other kitchen sink libraries over some individual modules on npm is that you know that they have seen some real world action and that they have been build and/or vetted by developers you trust.

:+1:

@stoeffel

However it would be nice, if we bump each other if someone gets an issue that the other may also have.

Or just depend on the same module. Lo-Dash follows semver so with the proper range ^ Underscore.string would get fixes and improvements automatically.

You could always just test-flight it. Worse case it's not the right fit and you pull them out.