# RFC: Splitting the library into packages

**URL:** <https://discuss.prosemirror.net/t/rfc-splitting-the-library-into-packages/330>\
**Category:** Uncategorized\
**Created:** [June 13, 2016, 2:44pm UTC](https://discuss.prosemirror.net/t/rfc-splitting-the-library-into-packages/330 "2016-06-13T14:44:39Z")\
**Posts on this page:** 1\
**Showing post:** 15

<div class="post-metadata">

**Author:** ![adrianheine](https://discuss.prosemirror.net/user_avatar/discuss.prosemirror.net/adrianheine/32/28_2.png) [@adrianheine](https://discuss.prosemirror.net/u/adrianheine)\
**Post date:** [July 1, 2016, 8:55am UTC](https://discuss.prosemirror.net/t/rfc-splitting-the-library-into-packages/330/15 "2016-07-01T08:55:17Z")

</div>

> [@marijn](#):
>
> A table schema must be useable outside of the browser, so it can’t import the editor module. A command, on the other hand, will need to interact with selections and other editor-specific things, and thus must import the editor module.

In general, you could break dependencies from the command on the `editor` module by injection or with cheap interfaces. So, `command-table` has two dependencies on `editor`: It uses `Selection.findFrom`, and it takes arguments of type `ProseMirror`. The former dependency can be turned into one similar to the latter by passing `Selection.findFrom` as first argument into `moveCell`. That way, you conceptionally use types from from `editor`, but have no dependencies on the JS code level.

To get rid of these logical dependencies, you could introduce a (smaller) interface wrapping the editor that schema, command and editor can depend on.

These are just some theoretical considerations, I’m not arguing that we should do this.

---

_[View the full topic](https://discuss.prosemirror.net/t/rfc-splitting-the-library-into-packages/330)._