string-ts roadmap

[gustavoguichard]

Roadmap for v1

As I was asked by @p9f I don't have a specific Roadmap for string-ts yet, but will try to outline my ideas and people can contribute with ideas to this discussion so I can update the list.

Based on MDN's list of String.prototype functions I got some inspiration for the useful native counterparts. I don't think we should implement every function just for the sake of it, though.
Here follows a list where:
✅ = implemented
◻️ = not yet implemented
🟠 = partially implemented
❓ = not sure if it makes sense
🚫 = not gonna implement

---

• ❓ String.prototype.at() - unsure as charAt is similar and has better support, we could just implement negative indexes to it
• ✅ String.prototype.charAt()
• 🚫 String.prototype.charCodeAt()
• 🚫 String.prototype.codePointAt()
• ✅ String.prototype.concat()
• ✅ String.prototype.endsWith()
• 🚫 String.fromCharCode()
• 🚫 String.fromCodePoint()
• ✅ String.prototype.includes()
• ❓ String.prototype.indexOf()
• 🚫 String.prototype.isWellFormed()
• ❓ String.prototype.lastIndexOf()
• 🚫 String.prototype.localeCompare()
• 🚫 String.prototype.match()
• 🚫 String.prototype.matchAll()
• 🚫 String.prototype.normalize()
• ✅ String.prototype.padEnd()
• ✅ String.prototype.padStart()
• ✅ String.prototype.repeat()
• 🟠 String.prototype.replace() - using Regex will result into the loose string type
• 🟠 String.prototype.replaceAll() - using Regex will result into the loose string type
• 🚫 String.prototype.search()
• ✅ String.prototype.slice()
• ✅ String.prototype.split()
• ✅ String.prototype.startsWith()
• 🚫 String.prototype.substring() - slice may be enough
• 🚫 String.prototype.toLocaleLowerCase()
• 🚫 String.prototype.toLocaleUpperCase()
• ✅ String.prototype.toLowerCase()
• 🚫 String.prototype.toString()
• ✅ String.prototype.toUpperCase()
• 🚫 String.prototype.toWellFormed()
• ✅ String.prototype.trim()
• ✅ String.prototype.trimEnd()
• ✅ String.prototype.trimStart()
• 🚫 String.prototype.valueOf()

Other common string methods:

• ✅ camelCase
• ✅ constantCase
• ✅ delimiterCase
• ✅ kebabCase
• ✅ lowerCase
• ✅ pascalCase
• ✅ snakeCase
• ✅ titleCase
• ✅ upperCase
• ✅ truncate
• ❓ dedent

Remember that the aim of this library is to have the same expected result at both type and runtime levels, so if you are going to implement one of these methods and you can only do it partially, make sure you modify the runtime implementation to behave the same as the type-level. Here is an (outdated because I solved it) example of it.

[gustavoguichard]

Roadmap for v2

Here are the decisions we took too early that will cause breaking changes so they'll have to be a major bump.

Differentiate between casing functions that rely on the words method from those that are native

From the issue #35

Like in lodash, we should differentiate the methods like camelCase - that should probably not be prefixed with to (e.g: toCamelCase) that will omit separators - from methods like toLowercase - which replicate the native behavior that will not omit separators.

This will require us to implement new methods lowerCase and upperCase, as well as renaming the current ones to camelCase, constantCase, etc. We'll just keep the toLowercase and toUppercase methods as they are.

We should also clarify that on the docs.

Tree-shaking

To reduce the impact of this library in the bundle size we should strive for enabling tree-shaking or we should even consider doing isolated exports like lodash does:

import pick from 'lodash/pick'

As we started supporting more methods the size of this library surpassed 1kb gzipped and that should be reduced.

[p9f]

about the renaming - as far as I understand it would not need to change the behaviour of any existing function name, right?

So maybe we could do it in a minor version - deprecating (but not removing) the old functions?

[gustavoguichard]

Good idea @p9f !
We can start deprecating right away, both types and runtime functions.