Incorporate deckardcain

[kylef]

There is various logic for ADD detection in multiple places (fury adapters, deckard cain etc). We should deduplicate these efforts and provide a detection interface to API Elements JS (/Fury) which doesn't require having all of the adapters and the adapter logic should utilise it.

[honzajavorek]

BTW I'm wondering whether deckardcain shouldn't be a part of the monorepo as well. If API Elements is a uniform interface to work with API descriptions, it seems to me deckardcain kind of fits in as well.

[kylef]

BTW I'm wondering whether deckardcain shouldn't be a part of the monorepo as well

deckardcain isn't in ADT bounded context, some other team created the library. Although I am suggesting here is that we provide some equivilent package apart of API Elements which can replace deckardcain.

[honzajavorek]

I have an idea on who was the team apiaryio/deckardcain@85fddda. I think we originally created it as part of the efforts to have parsing as a service. Inherently, I'd suggest ADT to adopt it and decide its future. What I was suggesting basically was that even though it's useful as a separate package, it could live in the monorepo, be used by the API Elements toolchain perhaps internally, and can be easily picked up by projects depending on API Elements.

[kylef]

Took a look into deckardcain again, I think we need to think about browser testing first. #21 is the closest thing that tracks anything browser related.

deckardcain is used in browser by Apiary and currently its CI is configured with a browser tests using Karma. We should figure out how to do browser testing here (monorepo, circleci etc) and then move it over.