Bump DOMPurify from v2.0.8 to v2.0.11

[NicholasEllul]

The full changelog can be found here --> https://github.com/cure53/DOMPurify/releases, but here is a screenshot for reference:

I also bump the DOMPurify types dependency to 2.0.2 since it includes the new interface for the ADD_DATA_URI_TAGS config that was added.

[kkomelin]

Thank you @NicholasEllul for your contribution!

[kkomelin]

@NicholasEllul I'm thinking about what kind of version increase to choose for this update (minor or patch).
Noticed that dompurify doesn't follow semantic versioning precisely. For instance, some patch releases, e.g. 2.0.8, had new features. And new features should be released as a minor version according to the semantic versioning.
What do you think? What would you recommend?

[kkomelin]

I think I will create a minor release this time because I've also added a simple smoke test for this repo and integrated with TravisCI #5
However, I'm still not sure what to choose in the future - minor or patch on dompurify version bump?

[kkomelin]

Released 0.3.0

[NicholasEllul]

I agree with you, it makes more sense for feature changes to result in a minor version bump instead of a patch in the version.

Another idea I thought of: To make it easy for people to know which DOMPurify version they are using, we could copy DOMPurify's versioning. In other words, when DOMPurify releases version 3.0.1 we update isomorphic-dompurify to 3.0.1 as well.

[kkomelin]

I like the idea of version mirroring with DOMPurify, and it makes a lot of sense, but what to do if we need to fix a bug in out project?

[NicholasEllul]

Hmm good point. I opened cure53/DOMPurify#446 in DOMPurify.

An idea for If they do start using correct semantic versioning:
What we could do is follow only DOMPurify's major and minor version numbers, then reserve the patch version on this repo to update whenever we fix a bug or DOMPurify updates their patch with a bug fix.

[kkomelin]

Created a separate issue to extract this topic from the closed PR.