Closed sichvoge closed 7 years ago
It also is a related to https://github.com/mulesoft/api-console/issues/258
I'm running into the same problem. Looks like the RAML parser cannot deal with situations where a library file tries to use another library or include type snippet files.
All referenced files are correctly downloaded. They appear in the network tab of the developer console of my browser.
When I rewrite that library file and remove all references to the other files, then the error disappears and the API console page renders again.
Do you have a small reproducible example?
I have been trying to create a minimum example for the past 20 minutes, but I cannot reproduce the problem. So I guess something else must be going sideways with my actual API project. Unfortunately I cannot share that project, since it's for a client of mine.
I noticed something though: when I remove just the uses
statement from my library file, and keep the !include
statements for the DataType files, then the API console loads again.
Never mind, I figured out the cause of the problem... it's the browser cache. Google Chrome doesn't re-download the updated include files even when I hit shift + F5, so it was downloading old files that contained errors. Clearing the browser file cache fixes the problem :-/
Perfect! So can we close that?
Yes, it was just a file caching problem
Well, the error is still not displayed.
$scope.vm.error = angular.extend(error, {
/*jshint camelcase: false */
buffer: (error.context_mark || error.problem_mark).buffer
/*jshint camelcase: true */
});
Error in this context does not contain context_mark nor problem_mark. Instead we have:
{
"parserErrors": [{
"code": 1,
"message": "JS-YAML: bad indentation of a mapping entry at line 188, column 14",
"path": "api.raml",
"range": {
"start": {
"line": 188,
"column": 13,
"position": 6023
},
"end": {
"line": 188,
"column": 14,
"position": 6024
}
},
"isWarning": false
}]
}
Oh, now I see. 365 solved that. Nevermind!
The
raml-loader-console
directive does not handle the new "errors" object schema accordingly to the new parser. It seems that this code was not updated, and now every time you use this directive alone plus an invalid RAML, you end up with the following:That obviously happens since the directive tries to access the buffer property, but it isn't there.
(error.context_mark || error.problem_mark).buffer
This is related to #313 and #314