Making ghost compatible with showdown main

[tivie]

Most of the bug reports here regarding markdown have already been fixed in showdown main so I've been working on adapting ghost custom extensions to run with showdown latest.

I've split ghost custom extensions into their own repository and ran them against showdown demo editor. I've also tested them in ghost editor, although I haven't ran the automated tested as I haven't had the time to properly install and configure CasperJS on windows.

Some bugs are still present, most due to limitations in showdown's own extension system, which I'm planing to address in the next showdown's minor bump.

I'm planning on finishing the testcase for each extension in the next week and then issue a PR against ghost with the modifications.

In the meanwhile, I would love if you could take a look at the extensions themselves and give some feedback:

• https://github.com/tivie/showdown-ghost-imagepreview
• https://github.com/tivie/showdown-ghost-extra
• https://github.com/tivie/showdown-highlight
• https://github.com/tivie/showdown-footnotes

If you regard them as a good starting point, I can fix the remaining bugs, implement the rest of the features and switch the repos control over to you.

[ErisDS]

Hi @tivie, really appreciate the work going on here to try to bring Ghost into line with the work you've done to improve showdown.

The extensions look good in principle, my major concern is that if they are in a repository on their own it's a bit harder to keep them tested both standalone and as a full set working together. I guess we can do it inside Ghost, but the reason for moving them out was to keep it more self-contained (especially as we use these both client and server side).

I was wondering if it would make sense to keep our fork, just as a place to pull in these extensions and test them, but not touch any of the core showdown files any more so that it was easy to keep pulling in updates from showdown.

Or maybe there's some other way to manage all of this I haven't thought of?

[tivie]

@ErisDS I see.

I would personally go for a MITM approach, which perfectly fits your scenario.

• abstract testsuite: A new repository with the complete abstract BDD testsuite (basic, complex, interaction, edge cases, regression, etc.. all go here). No dependencies or dev-dependencies, just your usual input/output cases.
• extension: Each extension has it's own repository with the lib and the basic test-set against showdown. No soft/hard dependencies, only dev-dependency on showdown (and the abstract testsuite, if you wish).
• wrapper: Similar to your fork but its basically just a wrapper that runs the abstract testsuite against showdown+extensions. Soft dependencies on showdown+extensions.
• ghost: In ghost, you run the same test-suite (+specific ghost stuff tests) against the abstract testsuite in the ghost environment.

This way you keep your extensions separate which makes them more modular and testable. You can also safely juggle extension and showdown versions as you see fit.

But the main advantage is that "blaming" and rollback becomes really easy. Since the extensions are tested solo, with eachother (as a kind of bundle) and in ghost context, you can keep a relatively straightforward BDD testsuite and, depending where(and when) it breaks, you can blame showdown, an extension or ghost.

Also, you can keep your "wrapper" with soft dependencies, testing against showdown/extension latest while making ghost dependencies hard. This has side benefit that with a CI tool, you get a range of "compatible" showdown+extension version arrangements for free.

[kevinansfield]

Now that 1.0 is very nearly released changes of this size and with potential breaking changes won't be pushed forward in the LTS branch.