Wrapping node-imgur

[KenEucker]

Yo dawg, I heard you like API wrappers. So I wanna build a wrapper around your API wrapper of Imgur so I can wrap what you've wrapped while others wrap what I wrap!

@kaimallea The work you've been doing on imgur@new is really great stuff. I haven't been able to keep up with you! I hope it doesn't offend you, but I copied all of your code into a new biketag-api project of my own and am in the process of ripping it all apart to figure out how the toaster toasts the bread. I'm getting the hang of it now, I think, and I feel like this work will help me contribute back to the node-imgur project again in the future.

I'm new to TypeScript and new to all of the amazing tooling that you've included in this project, so if you have the chance to give my project a peek I'd love some feedback. Just understanding where I am now in comparison to the recent changes you've pushed in the last week (getting rid of babel, for example) would be a lot of help I'm sure.

Some context here: The BikeTag Project, spread across several repositories on my GitHub profile, is an open-source platform for playing the BikeTag game and we offer the server at biketag.org for anyone who wants to run a BikeTag game in their city. For the last three years, since starting the project from scratch, I've been using your node-imgur package for managing interactions with Imgur. Imgur makes our entire app possible, as all of our images and data are stored on Imgur and within the title and description metadata included in each upload.

The new BikeTag Api that I am developing, in the biketag-api repository, will take advantage of imgur@next and is a full rewrite for our platform's API. I wanted to mimic how you have developed the node-imgur package here because for now, and in the indefinite future, and as far as we can see: we will continue to use the Imgur API. That being the case, I wanted to make it so that the interactions with Imgur that currently exist in our project wire up to the new BikeTag Api without much friction.

So! All that out on the table, I wanted to let you know that I'm running a hackathon this weekend for a small group of developers jumping in on the new BikeTag Api and BikeTag Vue App. If, at any point, you had a moment to jump into the slack channel or other avenues that we will be using for the hackathon it would be great to chat with you! ( you can join our slack here )

I know you're busy and that we have a timezone difference of some kind. I won't be offended if you decline. Just wanted to extend the offer for you to check out how your API is being used on a project in the wild! Thanks again for all your recent work on this software!

[kaimallea]

@KenEucker hey, sounds awesome! I am not offended at all, this is what open source is all about! I'm happy it's serving additional purposes and that you feel it's a good enough example to learn from. Also great that you've been able to use the library for the last several years!

I probably won't be able to participate in the hackathon (weekends are family time for me), but maybe in the late evening I can stop in and say hi!

[KenEucker]

@kaimallea The hackathon begins!!

I am 90% of the way through a refactor of imgur@next to drop support of fs and support streams, and to replace got with axios. This is an attempt to make the node-imgur package support both nodejs and the browser. As axios contains this support, the only remaining functionality to abstract out was the use of fs to run createReadStream for filepaths. My thinking is this: change the "string" support to be used as a "url" upload instead of calling createReadStream on the string passed in.

To summarize the work I'm doing:

1. Replace got with axios. Replacing Response wrapping.
2. Add a helper method to utils.ts convert from the underlying response object to an ImgurApiResponse.
3. Replace the use of path strings resulting in a call to createReadStream, with the string parameter to be interpreted as a "url" upload.
4. Remove upload methods specific to videos and files in favor of streams for these upload types.
5. Update the readme to show the external use of the fs.createReadStream for local file uploads using the API.
6. Add readme instructions for creating streams in the browser and uploading via the browser.
7. Reconfigure the build process for the package to include webpack bundling as a umd module.
8. Update tests.
9. Profit.

What are your thoughts on taking advantage of the move to a v2 and dropping direct fs support to make this API usable in both nodejs and the browser? I was thinking that this would plug really well into the CLI counterpart we've discussed. The CLI could include the fs wrapping and allow for use within nodejs as a module almost exactly how node-imgur is used now and would be used with v2.

[KenEucker]

Update: I finished the refactor mentioned above.

Items completed:
1. Replace got with axios. Replacing Response wrapping.
2. Add a helper method to utils.ts convert from the underlying response object to an ImgurApiResponse.
3. Replace the use of path strings resulting in a call to createReadStream, with the string parameter to be interpreted as a "url" upload.
4. Remove upload methods specific to videos and files in favor of streams for these upload types.
5. Update the readme to show the external use of the fs.createReadStream for local file uploads using the API.
7. Reconfigure the build process for the package to include webpack bundling as a umd module.
8. Update tests.

LEFT TO DO:
6. Add readme instructions for creating streams in the browser and uploading via the browser.
9. Profit.

Nice.

[KenEucker]

Circling back here to show my work:
#172

One thing I feel that needs to be added is tests for streams. Tests using fs could probably have remained in this code for now, but I feel confident that testing a stream without using fs will retain portability while the underlying stream support will remain for the use of fs elsewhere.

The PR doesn't pass the tests and I'm not sure why because I can run the tests on my machine and they all pass -- hence the ability to commit in the first place. I will look into that but it would be nice to have another pair of eyes on it.