-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorporate deckardcain #126
Comments
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. |
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. |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: