Is your feature request related to a problem? Please describe.
For example when working with path uris you may want to end or start the path with /, except when it already does not have such prefix or suffix. This may be necessary to normalize base paths coming from user input or from configs.

Describe the solution you'd like
A conditional Prefix() and Suffix() method that would add suffix/prefix in case it does not exist.
In some languages/libraries these are also called str_start, str_cap, str_finish etc..

Describe alternatives you've considered
I have done this in couple of projects, but I'd rather use some good existing/common library instead of copy-pasting utilities package from project to project.

Additional context
I'd make a PR, but it requires an issue to exist as I read from contributions guidelines.

Proposed code examples:

import "strings"

// Prepend a string to a string if it does not already start with same string
func Prefix(str, prefix string) string {
	if strings.HasPrefix(str, prefix) {
		return str
	}

	return prefix + str
}

// Append a string to string if it does not already end with same string
func Suffix(str, suffix string) string {
	if strings.HasSuffix(str, suffix) {
		return str
	}

	return str + suffix
}

Describe the bug
Similar to recent LcFirst patch, if the first character is multi-byte then the additional bytes are duplicated.

To Reproduce
Steps to reproduce the behavior:
see new test case

Expected behavior
No duplicate bytes.

like snake("foo-bar")?

Describe the bug
"true" is not treated as a valid boolean string, because it is not
lowercased in the True slice.

To Reproduce
Steps to reproduce the behavior:

1. Call stringy.New("true").Boolean()
2. Panic

Expected behavior
Should return true.

Screenshots
See https://go.dev/play/p/YZ2SqgZTmOp

Additional context
PR is forthcoming that fixes the bug and expands the boolean tests

Since this library wraps a lot of built-in functions, I miss this one(essentially a snake case but with spaces):
https://pkg.go.dev/strings#Title

I use a lot of CamelCase function calls, and in the pprof report I see that the lion's share of the CPU is spent on compiling constant regular expressions.

I would like remove re-compilation of regular expressions on each request for helper functions.

Soulution:
#26

Something that converts from CamelCase, snake_case, kebab-case to Sentence case

e.g. ThisIsCamelCase to This is camel case

func (i *input) SentenceCase(rule ...string) StringManipulation {
	input := getInput(*i)
	wordArray := caseHelper(input, false, rule...)
	i.Result = strings.Join(wordArray, " ")
	return i
}

I have code like this but it is pretty ugly (converts to snake case then replaces _ with -):

s := stringy.New(str)
str = strings.ReplaceAll(s.SnakeCase("?", "").ToLower(), "_", " ")
return stringy.New(str).UcFirst()

Also it would be nice to be able to chain ToLower() w/o a new stringy.

If the package name is "stringy", the project name must be named like it ("stringy"), not "Stringy".

that would be nice to configure acronyms to make specific combinations be treated as words.
words like: IPv6 -> ipv6, CDNs -> cdns

The tags in Go must be like "v2.0.0"

Why is not CamelCase returning a StringManipulation interface like KebabCase or SnakeCase?
stringy.New(f.Name).CamelCase().LcFirst() better than stringy.New(stringy.New(f.Name).CamelCase()).LcFirst()

It's not only about readability. Also about standardization.

Describe the bug
Currently, some basic functionality such as snake case formatting uses a lot of memory allocation (up to 70 malloc/op).

It is really a let down having that kind of performance for a helper library.

To Reproduce
Steps to reproduce the behavior:

1. Call function 'SnakeCase().String()' using go's benchmark.

Expected behavior
Reduce mallocs.

Describe the bug
The current LcFirst assumes the leading character is a single byte. When it's multi-byte an extra unrecognized character is added with the extra bytes.

To Reproduce
Pass in a string with its first character being a capitalized multi-byte character.
New("ΔΔΔ").LcFirst() = δ�ΔΔ, want δΔΔ

Expected behavior
A multi-byte leading character would not cause duplicated bytes.

Additional context
I'll be opening a PR to address it this weekend. If it's accepted I'll repeat submit one for UcFirst as well.