Add support for Libraries

[econchick]

Related roadmap page

• Support for:
  • [ ] parse uses in the Root of the API
  • [ ] parse object according to types within library file:
  • [ ] Resource Type
  • [ ] Trait
  • [ ] Data Type
• Potential (not sure if good idea or not):
  • [ ] Create a LibraryNode object attached to any object that has uses property
  • contains following properties:
    • [ ] usage
    • [ ] uses -> points to more libraries
    • [ ] types -> parsed into Data Types
    • [ ] traits -> parsed into TraitNode s
    • [ ] resourceTypes -> parsed into ResourceTypeNode s
    • [ ] annotationTypes -> parsed into Annotation Types
    • [ ] (<annotationName>) -> parsed into Annotations
    • [ ] securitySchemes -> parsed into SecurityScheme objects
    • [ ] schemas -> parsed into schemas object
• [ ] Even if the above LibraryNode isn't implemented, the properties should be parsed into their respective objects accordingly (outside of the library, within the api itself), e.g. just like how any other resource type, trait, and data type would behave if defined in one file or multiple files.
• [ ] Validation for the above properties
• [ ] Validation for #%RAML 1.0 Library file header
• [ ] Documentation
• [ ] Test coverage

[postatum]

Hi @econchick. Will addition of RAML v1.0 support break anything for RAML v0.8? (except for resource_type.optional).

[econchick]

Hey @postatum - I don't believe so, no. Not to the API of the library (besides optional). Mostly additions. Some to fix 0.8, most for 1.0 features.

However there was an introduction of a different repr of the RAML object; not sure if one would consider that a breaking change?