The devDependency @types/underscore was updated from 1.9.3 to 1.9.4.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/underscore is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

raml-org/raml-spec#234

The way how uses defined in RC2 is hard to represent in terms of definition system, we should think through it and deal with it somehow.

HasNormalParameters -> MethodBase -> Method

Seems that gets inherit from LibraryBase no?

As far as I can see; describedBy (which is a SecuritySchemePart) should only have the following:

• headers
• queryParameters
• responses

There are a lot information that are currently not reflecting that repository. We need to clean that up.

I am not fully sure about the usefulness of the system types. I understand why they have been created in the first place, but its different know. Could we remove them and, for example, use simple native types for baseUri; something like: baseUri? : string. That will also avoid any boilerplate code in any generated interfaces in other languages.

The devDependency @types/node was updated from 12.11.6 to 12.11.7.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

raml-org/raml-spec#329

According to the RAML 1.0 specification, only the following HTTP methods should be available:

• get
• patch
• put
• post
• delete
• options
• head

The definition system seems to ask for more. See here

Also the available methods here are wrong too.

🚨 Reminder! Less than one month left to migrate your repositories over to Snyk before Greenkeeper says goodbye on June 3rd! 💜 🚚💨 💚

Find out how to migrate to Snyk at greenkeeper.io

The devDependency @types/node was updated from 13.13.4 to 13.13.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

raml-org/raml-spec#244

raml-org/raml-spec#288

From @sichvoge comment to PR

Method: Actually inherits all properties from MethodBase which inherits its properties from >HasNormalParameters. But again I am seeing a lot properties that has been defined explicitly. BTW, >HasNormalParameters is really not a good name.

This is because Konst was overriding property descriptions for subtypes (same in all related cases). I am removing this overrides when I see them now.

I am removing this override as soon as I see them right now, but we need to invent some way of customising documentation in sub types.

Extending from RAMLLanguageElement would mean that you are able to define a description at the root-level of an API. That was not possible in 0.8.

raml-org/raml-spec#202

I have implemented a workaround with using any as a type of example property, and plan to implement custom parsing for it in the parser, but this is not we want actually. So we need to deal with it somehow.

MethodBase, Method, Trait: Should that class not inherit all its properties from Method. As per the spec >there should not be any difference, accept that Trait has an additional usage property. Don't really see >why we would need MethodBase anymore.

ResourceBase, Resource, ResourceType: Same as my previous points; do we really need >ResourceBase. As per spec, ResourceType should also be a resource and hence inherit all its >properties plus define an additional usage property.

The need for separation in this case is caused by different restriction on the keys (for example Trait can have any name, but Method keys are restricted to valid http method names. (same about Resource and ResourceType. But in fact we may think about different representation for this.

raml-org/raml-spec#341

The devDependency rimraf was updated from 2.6.3 to 2.7.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

rimraf is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

raml-org/raml-spec#239

Looking at TypeDeclaration I can see two methods: example and structuredExample.

1. What is the difference between those two?

2. Where is examples?

Can we rename that class; it does not really say anything. What are normal parameters etc. What about just saying HasParameters?

In RC2, even scalars can have annotations, so annotations property falls out of definition system

SecuritySchemeSettings: Do we not support any annotations for that? I can see >SecuritySchemeSettings: as target inside the annotation target table

We can not use RAMLLanguageElement as a sign that element may have annotations any more, so we should invent a new way of handling this.

raml-org/raml-spec#307

raml-org/raml-spec#287

raml-org/raml-spec#228

raml-org/raml-spec#222

Same as #46. You can not define description at this level.

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The devDependency @types/underscore was updated from 1.9.4 to 1.10.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/underscore is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The dependency underscore was updated from 1.9.2 to 1.10.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

underscore is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴