Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Roadmap for v1.0.0
See original GitHub issueThis is a list of features I would love to see in the first major version of tiptap. (WIP)
-
Overhaul components Replace scoped slots with components (see #20). Add
<editor />,<editor-menubar />and<editor-menububble />components. Implementing separated components lets us nest markup more easier. -
Improve commands Currently you can only register one command per extension (see #44). Sometimes this is limiting. For example, it would be nice to register an undo and redo command in the HistoryExtension. It would make sense to rename
commandtocommands. -
Better support for Tree-Shaking (see #16)
-
Unit tests + coverage A minimum of unit test + coverage should be part of this release.
-
Setup a CI server (e.g. Travis)
I am open to further suggestions 🙌
Issue Analytics
- State:
- Created 5 years ago
- Reactions:5
- Comments:11 (8 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I thought about possible topics for the version 1.x and the following came to my mind:
Unit tests + coverage
After changing the source code a bit I think that a minimum of unit test + coverage should be part of this release as well. The only way I had to check if my changes didn’t break anything was to manually go through all examples and somehow try to break them. This approach works well to quickly prototype/propose features but it is very error prone: even the most dedicated developer can forget some corner case and some regressions may get introduced. It is also very counter productive, as I had to rerun all the manual test session for every change that could possibly introduce a bug.
Given that context I want to propose adopting Jest and come up with a minimum of coverage to be set as a goal.
Setup a CI server
I would go with Travis as it’s free for open source projects and it’s very well integrated with node/npm already. With tests (and the recent addition of linting) we could mark pull requests as not ready as soon as they hit the CI server with violations/broken tests.
I do believe that there is something fishy with tree shaking and I would make #16 a goal for this Roadmap. What are your thoughts?