Switch to a Promise interface

[sindresorhus]

For the async API. Instead of a callback.

[wooorm]

For the rules/externals? Yup, why not! Shouldn’t be very hard!

[sindresorhus]

Pretty much for everything, but was mainly thinking of the callback here: var file = remark().use(lint).process('## Hello world!', () => {});

[wooorm]

With the release of the master branch, in ± a few minutes, it’ll be possible to return promises from rules. It’s already possible to return promises from remark plug-ins too.

However, I personally don’t want to support promises in the outward remark API, so that (.process(doc, cb)) will remain a callback!

[sindresorhus]

With the release of the master branch, in ± a few minutes, it’ll be possible to return promises from rules. It’s already possible to return promises from remark plug-ins too.

Awesome! Thanks for being so responsive :)

However, I personally don’t want to support promises in the outward remark API, so that (.process(doc, cb)) will remain a callback!

You don't have to switch though. You could easily support both. Return a promise if no callback is provided. That's a very common thing to do for authors that are not convinced about promises, but want to make it easy for anyone to use their API.

[wooorm]

Unfortunately not: the vfile itself is already returned, which is useful, as the API is often sync.

If that’d be possible I’d be OK with it, but I value the sync API too much!

[sindresorhus]

Having an API be sync or async depending an argument is generally considered an anti-pattern. Would be better to be explicit about with through an option or even better a separate method.

• .run()
• .runSync()

Or the inverse.

[sindresorhus]

If you want to preserve backwards compatibility, you could add a .runAsync() method.

[wooorm]

Currently it’s more that the plugins someone uses defines the process. You’ve convinced me though: superseded by unifiedjs/unified#8!