>Correctly handles Unicode emoji and complex symbols
I'm no JS/TS expert, but this sounds like it could be a case of making something behave like an inexperienced dev would expect at the cost of making it behave unexpectedly to an experienced dev.
JS strings are sequences of UTF16 code points, and that's part of their public API (e.g. 'split'), right? That's JS's choice (or mistake, depending on your feelings). So I would expect 'chonk' to treat strings as what they are. And then add a flag or separate method ('chonkGraphemes') instead.
But maybe this kind of "helpfulness" is normal in 3rd party JS APIs?
Hi! Great idea — overall, all the edge cases are handled really well.
That said, I think it would be good to add a config for the available processing options (similar to how it’s done in markdown-it, for example) to better support expected behavior.
I’ll give it some thought and work on implementing it!
See, this is what I don't get about the JS/NPM ecosystem.
This is 140 lines of code, with comments. Yet it gets a whole separate repository, with a cute name, fancy README, little emoji graphics and a bespoke logo. All of this for functionality that other languages have in their stdlib.
It's almost like it's more of an exercise in marketing than an attempt to actually make a useful library.
Yeah, that’s just how the JS ecosystem works — even small utilities often get published as separate packages so they can be reused without copy-pasting. I originally built this for myself, and figured it might be useful to others too.
As for the name and README — I don’t really see it as marketing. I just prefer to make things clear and easy to use for anyone who stumbles across it. Even if it’s a small project, why not present it properly?
If that comes off as overkill, fair enough. I’d rather overdeliver than leave people guessing.
Cool! One thought:
>Correctly handles Unicode emoji and complex symbols
I'm no JS/TS expert, but this sounds like it could be a case of making something behave like an inexperienced dev would expect at the cost of making it behave unexpectedly to an experienced dev.
JS strings are sequences of UTF16 code points, and that's part of their public API (e.g. 'split'), right? That's JS's choice (or mistake, depending on your feelings). So I would expect 'chonk' to treat strings as what they are. And then add a flag or separate method ('chonkGraphemes') instead.
But maybe this kind of "helpfulness" is normal in 3rd party JS APIs?
Hi! Great idea — overall, all the edge cases are handled really well. That said, I think it would be good to add a config for the available processing options (similar to how it’s done in markdown-it, for example) to better support expected behavior. I’ll give it some thought and work on implementing it!
Thanks for your support! Added separate processing, now it seems the behavior is more obvious
No src/, only a minified index.js dist?
I did it primarily for my needs. But the idea is good, I'll add it today!
Added if you're interested :)
See, this is what I don't get about the JS/NPM ecosystem.
This is 140 lines of code, with comments. Yet it gets a whole separate repository, with a cute name, fancy README, little emoji graphics and a bespoke logo. All of this for functionality that other languages have in their stdlib.
It's almost like it's more of an exercise in marketing than an attempt to actually make a useful library.
Yeah, that’s just how the JS ecosystem works — even small utilities often get published as separate packages so they can be reused without copy-pasting. I originally built this for myself, and figured it might be useful to others too.
As for the name and README — I don’t really see it as marketing. I just prefer to make things clear and easy to use for anyone who stumbles across it. Even if it’s a small project, why not present it properly?
If that comes off as overkill, fair enough. I’d rather overdeliver than leave people guessing.