datauri 3.0 - RFC 🎉

[heldr]

Since 1.0 release, datauri has taking off in matter of popularity.

Based on that, I invited @ruyadorno and @caiogondim to be part of this, moving plans to next level with a new github org. This is the first step on the challenge to turn an old pet project into series of robust and open community tools.

Next step will be 2.0 version, which is expected to get a considerable perfomance boost, better docs and build process improvements. Those changes will not only help users but also contribution experience.

Besides a major release, compatibility might be taken into account, since many node modules rely on datauri.js as main transformer. I've listed below some possible things to change:

Build and test

• Keep datauri module and datauri-cli on a single monolithic repo using lerna.js instead of current code, or split them in 2 github projects?
• Use jest as test runner instead of mocha.
• For code coverage, use istanbul instead of blanket.js. Should keep coveralls? Anything newer and more interesting?
• Run node benchmark tests. For this topic, I might grab some ideas from fast-memoize, since I'm not an expert on this subject yet. I'm open for suggestions/help though.
• Write code for node.js 6+ and support old versions with Babel transpiler, or move back to fully es5?

Module core. AKA npm i datauri

• Switch back to functional programming paradigm and implement deprecation warning when class is instantiated. I believe this will bring more flexibility for the module improvements below.
• Promise as default async approach, support error notice and suggest callback for node older than 0.12
• Bulk transform when an array is given. Ex.: datauri(['image1.jpg', 'image2.jpg']).
• Optimize string manipulation if possible. How caching calls based on file hash would affect the experience?
• Deprecate this[metadata_category] scope to follow class deprecation. Return a immutable object or just remove it at all.
• Split, when possible, each method into new files. This brings more modularity to the code and make things straight to the point. Example require('datauri/buffer').
• Improve streams to support pipe instead of the current readable approach. Do not extend Stream class like 1.0 does. Probably moving it to a module like datauri/stream could be a kick start.
• Deprecate synchronous calls? Generators are settle, not to mention async and await already on node nightly builds.
• datauri-cli install notice if datauri is executed on cli. I forgot to implement it on version 1.

CLI. AKA npm i -g datauri-cli

• Pipetize it! cat image.jpg | datauri --copy.
• Match glob expressions datauri images/**/*.png --css, that's where array bulk calls propose and Promise.all would act.
• Support download? datauri https://image.jpg. In fact curl -0 url | datauri would solve it though.

Docs

• Create a js.org webpage from markdown? Or stick with npm/github docs? I was wondering something like Apollo Client's one.

Future minor/pos 2.0 releases

• Time for type systems? I'd go with flow.
• With core being split into files, a web version using File api or Canvas tag would be nice.

datauri@next ideas, and possible datauri org projects

• Remove deprecated features.
• Browser plugin?

[ruyadorno]

Build and test

• Keep datauri module and datauri-cli on a single monolithic repo using lerna.js instead of current code, or split them in 2 github projects?

While Lerna is raising in popularity for larger projects, for the "lib + cli" case trend seems to go the other way these days. I think most people like having separated repos since it helps defining responsibility of each module and gives more flexibility for maintainers while reducing the overall size for people consuming only the library. With this in mind I would prefer to move forward with 2 github/npm.

• Use jest as test runner instead of mocha.

No strong feelings either way, we should consider that a change is always an extra effort that will be time consuming. I think it's safe to have this on the backlog with a lower priority.

• For code coverage, use istanbul instead of blanket.js. Should keep coveralls? Anything newer and more interesting?

Same thing as above, maybe with a higher priority though since it's probably a less effort-demanding task and Istanbul is the standard for coverage these days.

• Run node benchmark tests. For this topic, I might grab some ideas from fast-memoize, since I'm not an expert on this subject yet. I'm open for suggestions/help though.

I'll defer to whatever @caiogondim recommends for this one since I have no experience benchmarking libraries.

• Write code for node.js 6+ and support old versions with Babel transpiler, or move back to fully es5?

Is there any real reason to move back? I think ES6+ is def here to stay and Babel transpilation is popular enough.

[heldr]

@ruyadorno Thanks for the input! Very reasonable thoughts.

One more thing

• Use Typescript and expose it's .d.ts files right into the repo.

VS.

• Expose types at @types/datauri

[jaulz]

@heldr I think exposing types as part of this package makes more sense. @types is actually only used if the maintainer does not like them to be in the repository but since you already proposed it i assume you are in favour of it 😊 Let me know if you need help with it or are you already working on it?

[heldr]

Closing this since for now I'll be focusing only in TS types.