I'm thinking about moving the following modules from my personal Github sstur to draft-js-utils. Any thoughts on if that's a good idea?

• draft-js-export-html
• draft-js-import-html
• draft-js-export-markdown
• draft-js-import-markdown
• draft-js-import-element (used by import-html and import-markdown)

I was thinking more about this and I started to dislike the idea that we have to pass anchorKey and focusKey to the method.

If @ianstormtaylor would add his getSelection method from https://gist.github.com/ianstormtaylor/cfcaa8df52fb574e02c908f100fb29be to the utils (or we can do it if he's fine with it) then getSelectedBlocks could accept either:

• a custom selection state
• an editor state
• a content block (even though that wouldn't make a lot of sense in this case)

We'd reduce the number of arguments from 3 to 1 and add more flexibility to it. Thoughts?

I would suggest to rename it to draft-js-utils and then republish it on npm.

For npm it's probably best if you publish it and then add others as owner. There is a command to do so: https://docs.npmjs.com/cli/owner

This should work npm owner add nikgraf.

@sstur You are using flow within your files, but the repo does not reference flow as dev dependency, nor is there any npm command to type check the code. Would you be up for fixing that? :)

This module has draft-js@^0.5.0 as a peerDep but the latest is ^0.7.0. Installing the current draft js and draft js utils breaks deployment on heroku as is.

I'm new to doing open source projects, and I just want to know if there are standards or if you have preferences on how PRs get approved.

Is it enough that one person approves and does the merge? Or should we approve the PR via a comment so that others are able to review it as well? And is it the person approving the PR that is pressing merge, or the person that created the PR?

ENTITY_TYPE.IMAGE is missing

I like the airbnb eslint config. What are your thoughts on it?

Full disclosure: I like trailing commas and semicolons ;)

I can imagine that this quickly will grow into an library with many utils while people only need few of them. I suggest we make the structure is done in a way that you directly can import each util like this:

// just import getEntityRanges without importing the whole library
import getEntityRanges from 'draft-js-utils/getEntityRanges';

This way people don't have to get the whole library. With tree-shaking activated it wouldn't matter, but as far as I understood this is not active by default in most webpack/browserify setups.

This is what I consider to be not ideal:

// import the whole lib and get getEntityRanges
import { getEntityRanges } from 'draft-js-utils';

What are you thoughts?

Yarn outputs:
warning "[email protected]" has unmet peer dependency "[email protected]"

This is better: ^3.0