Release 0.18.0

0.18 is out, with a long list of bugfixes, a few new features, and three cosmetic breaking changes, which rename properties for the sake of consistency (the old properties will continue to work, with a warning, until the next release).

Significant new features include:

  • The ability to control which marks can coexist in a more fine-grained way
  • A way to make parse rules only match inside a given ancestor node
  • The possibility to project steps onto and out of sub-documents
  • A more convenient way to update props
  • Access to the transactions that initially created the steps when sending steps in a collaborative setup
  • A new command that splits blocks (i.e. the enter key) without resetting the set of active marks

Release Notes

prosemirror-model 0.18.0 (2017-02-24)

Breaking changes

schema.nodeSpec and schema.markSpec have been deprecated in favor of schema.spec. The properties still work with a warning in this release, but will be dropped in the next.

New features

Node objects now have a check method which can be used to assert that they conform to the schema.

Node specs now support an atom property, and nodes an isAtom accessor, which is currently only used to determine whether such nodes should be directly selectable (for example when they are rendered as an uneditable node view).

The new excludes field on mark specs can be used to control the marks that this mark may coexist with. Mark type objects also gained an excludes method to querty this relation.

Mark specs now support a group property, and marks can be referred to by group name in content specs.

The Schema class now provides its whole spec under its spec property.

The name of a schema’s default top-level node is now configurable. You can use schema.topNodeType to retrieve the top node type.

Parse rules now support a context field that can be used to only make the rule match inside certain ancestor nodes.

prosemirror-transform 0.18.0 (2017-02-24)

New features

Transform.setNodeType now takes an optional argument to set the new node’s attributes.

Steps now provide an offset method, which makes it possible to create a copy the step with its position offset by a given amount.

docChanged is now a property on the Transform class, rather than its Transaction subclass.

Mapping instances now have invert and appendMappingInverted methods to make mapping through them in reverse easier.

prosemirror-state 0.18.0 (2017-02-24)

Breaking changes

Plugin objects now store their spec under a spec instead of an options property. The options property still works with a warning in this release.

prosemirror-view 0.18.0 (2017-02-24)

Breaking changes

Decoration objects now store their definition object under spec, not options. The old property name still works, with a warning, until the next release.

Bug fixes

Fix bug where calling focus when there was a text selection would sometimes result in state.selection receiving an incorrect value.

EditorView.props now has its state property updated when you call updateState.

Putting decorations on or inside a node view with an update method now works.

New features

Plugin view update methods are now passed the view’s previous state as second argument.

The place agument to the EditorView constructor can now be an object with a mount property to directly provide the node that should be made editable.

The new EditorView.setProps method makes it easier to update individual props.

prosemirror-keymap 0.18.0 (2017-02-24)

New features

Add a keydownHandler function, which takes a keymap and produces a handleKeydown prop-style function.

prosemirror-history 0.18.0 (2017-02-24)

Bug fixes

Fix a problem where simultaneous collaborative editing could break the undo history.

prosemirror-collab 0.18.0 (2017-02-24)

New features

sendableSteps now also returns information about the original transactions that produced the steps.

prosemirror-commands 0.18.0 (2017-02-24)

New features

New command splitBlockKeepMarks which splits a block but preserves the marks at the cursor.


This sounds good. The ability to put more marks of the same type onto the same content means for us that it may actually make sense to upgrade from 0.10. But I wonder: How stable do you think this is? Do you foresee more large breaking changes before 1.0? I don’t think I will be able to convince our team to go through more than one major upgrade before 1.0, so if there are more big changes coming up, it may make more sense to wait a little longer.

Do you foresee more large breaking changes before 1.0?


1 Like

Upgrade went smoothly! Thanks for the warnings on prop name changes. Also very excited to see marks gain exclusivity abilities - you may want to make links default to being exclusive (I already added this to my schema and it works beautifully).


No, I mean, feel free to do that in your schema, but neither HTML nor Markdown makes links exclusive, and I see no reason to make that the default (I often use code-font-links myself, for example, and occasionally strong ones)

Madness! :slight_smile: - fair enough - I’ll have to see if a use case presents itself where I want to back away from full exclusivity. For now though it is helpful. I found allowing things like bold within links was buggy in that it could easily result in multiple links. Maybe what I want is a way to say links cannot have any internal marks. So either the entire link is bold or none of it.

Here’s some generated HTML from the basic demo when I make the letter “k” bold in “links”:

<a href="">lin</a>
<strong><a href="">k</a></strong>
<a href="">s</a>

You can fix that by making links the first mark in your set of marks. I’m not entirely sure why that isn’t the case in the basic schema since, indeed, the HTML looks nicer with the link on the outside.

@marijn I’ve been giving the context field a try and it looks like the values can be node names or node groups. Can you confirm that node groups are valid input? Groups are not mentioned in the docs and I don’t want to use them if they might not be supported in the future. Edit: actually node group names do not appear to work. Any chance context can be changed to support group names?

I have a case where a node can have two different ancestors but context does not appear to support this. What do you think of adding support for something along these lines?

paragraph/ | list_item/ | foo/bar/

They were just node names, but accepting group names there is a good idea. I’ve made that change.

Too much complexity. For cases like that, just specify multiple parse rules with different context expressions.

Awesome :slight_smile: Thanks @marijn