mulesoft / osprey

Generate Node.JS API middleware from a RAML definition
Other
431 stars 66 forks source link

Does Osprey support minProperties? #127

Closed zero51 closed 7 years ago

zero51 commented 7 years ago

With the following RAML...

        patch:
          body:
            application/json:
              type: object
              properties:
                firstName?: string
                lastName?: string
              additionalProperties: false
              minProperties: 1

I would expect a request with blank body to fail, but it succeeds.

zero51 commented 7 years ago

Ditto additionalProperties. It seems to be ignored, which is a shame...

zero51 commented 7 years ago

@jstoiko: any guidance here? This and #126 are quite important to us. It's a great library, but there seems to be little activity. Is it still actively maintained?

jstoiko commented 7 years ago

@zero51: you raised some valid points. I should be able to get back to you by the end of the week with a solution to both issues.

Yes, this project is still actively maintained and a version with RAML 1.0 should be released soon. It's taking more time than expected to get it out and it's out of my control. Thanks for your patience.

zero51 commented 7 years ago

Thanks @jstoiko. I'm using the raml1.0 branch at the moment, and most of it works fine.

jstoiko commented 7 years ago

Hang in there @zero51, still working on addressing this and #126. Not as trivial as I originally thought. Shouldn't be much longer though. The good news is we'll be able to include those changes in the new (pending) release.

zero51 commented 7 years ago

Thanks for the update @jstoiko. Looking forward to playing with the new release...

jstoiko commented 7 years ago

@zero51: minProperties, maxProperties and additionalProperties should work now. Can you give it a shot?

zero51 commented 7 years ago

@jstoiko: minProperties seems to work now, although additionalProperties is still ignored. Also, I'm getting parse errors now on the RAML doc, even though Atom doesn't complain...

[xmldom error]  element parse error: Error: invalid tagName:<resourcePathName 
@#[line:1,col:17]
[xmldom warning]    unclosed xml attribute 
@#[line:1,col:18]

and

[xmldom error]  element parse error: Error: invalid tagName:<resourcePathName 
@#[line:1,col:14]
[xmldom warning]    attribute "|" missed value!! "|" instead2!! 
@#[line:1,col:15]

I have two resource types defined, which do make use of resourcePathName tags, but their implementation has not changed.

zero51 commented 7 years ago

Removing all the resource-type descriptions silences all but two parse errors. There was nothing particularly special about them...

description: Where the <<resourcePathName | !singularize>> resource can be found
zero51 commented 7 years ago

The line numbers in the parse errors don't ever seem to be anything other than 1, but the other two errors are a result of this line...

description: Base64 encoded version of <identifier>:<secret>, prefaced with 'Basic'

It seems that it no longer likes any angle brackets in descriptions.

jstoiko commented 7 years ago

Your issue seems related to what was reported here: https://github.com/mulesoft/osprey/issues/130.

Have you tried to parse your file using the parser directly? It seems like using the latest version might fix the issue you are reporting. If it does, then we should probably bump the version in Osprey. If it doesn't, then I suggest you file an issue here.

zero51 commented 7 years ago

OK, will have a look. I guess the additionalProperties issue still stands though?

jstoiko commented 7 years ago

I can't reproduce, i.e. additionalProperties works for me. Can you share a RAML snippet here?

zero51 commented 7 years ago

For this endpoint...

        patch:
          body:
            type: object
            properties:
              first_name?: string
              last_name?: string
            additionalProperties: false
            minProperties: 1

An empty body {} correctly throws...

invalid json (minProperties, 1)

However, the following bodies are permitted: {"foo": "bar"} and {"first_name": "Fred", "foo": "bar"}.

jstoiko commented 7 years ago

You were right. Should be good now. Can you give it another try?

zero51 commented 7 years ago

Sorry, same behaviour here.

jstoiko commented 7 years ago

you'll need to uninstall/reinstall all your dependencies specifically https://github.com/mulesoft-labs/osprey-method-handler

zero51 commented 7 years ago

@jstoiko: Ah, I just uninstalled the core lib. All looks good now. Thanks!

zero51 commented 7 years ago

BTW, just tried the RAML parser directly, and I get no errors. The warnings are still displayed by Osprey though.

jstoiko commented 7 years ago

that's odd. the version of the parser has just been bumped to 1.1.14 in Osprey which is the lastest release. did you uninstall and reinstall that dependency as well? can you check which version of the parser is installed?

zero51 commented 7 years ago
 ├─┬ osprey-router@0.4.0
│ │ ├── array-flatten@2.1.1
│ │ ├── raml-path-match@2.0.0
│ │ └─┬ router@1.1.4 (git+https://github.com/blakeembrey/router.git#cfe18f9d59adca65c24c9c951ebd43e9bf07937e)
│ │   ├── array-flatten@2.0.0
│ │   ├── debug@2.2.0
│ │   └── setprototypeof@1.0.0
│ ├── passport-oauth2-client-password@0.1.2
│ ├─┬ raml-1-parser@1.1.14
jstoiko commented 7 years ago

when you're testing with the parser directly, are you using the development version or the same 1.1.14?

zero51 commented 7 years ago

Same version, same RAML definition.

jstoiko commented 7 years ago

would you mind sharing you RAML?

zero51 commented 7 years ago

Can I email it?