Transient Purescript-Text-Encoding is overly burdensome.
Closed this issue · 20 comments
The transient dependency on the text encoding library is there to provide a very specific use-case that is not general to all users of this library, and thus makes more sense to be removed. Ideally this could be a two stage process where first a new library is released providing the needed functionality, and then the functionality in this library can be removed, alongside a link and explanation that a new library now provides this behavior.
This issue is being created in response to #19
Oh crap, this is especially needed as this underlying library is now deprecated.
https://github.com/inexorabletash/text-encoding
In the deriving library I'll want to try and abstract this problem out.... which means back to my old nightmare.
What if you restrict it to UTF-8? There's a small polyfill here that could serve as a starting point:
https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder
I lack a minimalist isomorphism to do the decode easily available. I don't remember the full history of the work I was doing.
I'm also thinking of working further at erasing the need for a polyfill in the other library, but that is more of a long term goal.
I kind of agree with the "breakout" library idea actually, as I'm considering improving another library I maintain which has minimal behaviour for base64 encoding, and wrapping these dependencies in a library specifically for working with strings, base64, and arraybuffers collectively.
Did you want to preserve some semblance of the string encoding/decoding for this lib here?
No problem on my side, I have only used binary arraybuffers myself.
If you were to release the stripped down version a la my PR here as another major version, I think I can commit to having a library up by the end of the weekend to provide the now missing functionality, and I could PR your Readme to include a note about what changed and how to resolve the problem.
What do you think?
Important to note I also removed the Show instance as it depended on a node-only inspect.
Would merging to a temporary branch suffice? @athanclark will probably change the API as well and 2 major bumps could be a bit strange...
Sure, I can always do my next library using a local fork copied into the directory. Make a branch for me to merge into and I'll update the PR.
I have created https://github.com/jacereda/purescript-arraybuffer/tree/v9 including your PR.
Cheers to that. So I assume we expect that @athanclark 's work will also end up here as part of the v9 release?
https://github.com/AlexaDeWit/purescript-arraybuffer-encoding This is where the new library will live btw.
I'm right in the middle of thoroughly testing my branch - I'll make sure to pull whatever you've changed. I don't have any form of text-encoding integration right now - I ripped out everything, so any upgrades should be smooth, and I haven't touched arraybuffer-types.
Sounds good. My changes also rip out text-encoding completely, so you may have to resolve conflicts if we did it differently.
@AlexaDeWit would -codecs be a better name since it will also have decoding?
or text-codecs...
I'll give the name some thought. My intent also intends to include working with a wrapped base64 type (still text underneath ofc), but yeah, I'm not fully happy with the name either. If/When I rename though that link will still be valid for a while to find under the new name. Github rename redirects are cozy.
purescript-arraybuffer-codecs maybe, minus the "text" bit. Is decent.
https://github.com/AlexaDeWit/purescript-arraybuffer-codecs renamed, I'll die on this hill and all that. <3
I think #23 will take a while.
I cherry-picked your changes to master and published v9.0.0. Thanks.
The v10 branch has been merged to master, tell me if you have any problem with the new API in your -arraybuffer-codecs.