Upgrade to raml-1-parser

[coltonlw]

Abao should be upgraded to use raml-js-parser-2

The new parser supports RAML 1.0, so upgrading to it is a major step towards RAML 1.0 support in abao

The mulesoft api-workbench atom add-on uses raml-js-parser-2. The new parser is capable of resolving jsonschema $ref's, which is how the api-workbench does it. This will keep $ref parsing behavior in abao consistent with mulesoft RAML tooling, and allow resolving $ref's that are local filesystem paths.

I have a feature branch where I upgraded abao to use raml-js-parser-2. My changes for abao to use raml-js-parser-2 are mostly functional in a prototype quality state, the last thing is actually getting the new parser to resolve the $ref's. I am working to figure this out and will keep you updated. Still need to fix some tests, but I can run my feature branch against our RAML spec and aside from the $ref resolution error it appears to work.

raml-org/raml-js-parser-2#481

My abao feature branch for using raml-js-parser-2 (tests still need updating, $ref parsing waiting on response from raml-js-parser-2 project)
master...flywheel-io:raml-1-parser

https://github.com/raml-org/raml-js-parser-2

[galkin]

raml-1-parser written in typescript. abao written in coffeescript.
I think, it is one of reason, why will be easier to develop abao with typescript, then coffeescript.
@cybertk what do you think?

[galkin]

@coltonlw, can you fix tests and make pull request?

[jweaver]

Hey guys, any update on this? I'm interested in this as well!

Thanks @coltonlw

[oshalygin]

@galk-in the transpilation of raml-js-parser-2 is still JavaScript at the end of the day, same as abao. One transpiles from coffee script and the other from TypeScript but the consumption is still at the JS level

For reference:

//gruntfile from abao
coffeecov:
      compile:
        src: 'lib'
        dest: 'lib'

raml-js-parser-2 just transpiles down via tsc

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "declaration": true,
    "noImplicitAny": false,
    "moduleResolution": "node",
    "removeComments": false,
    "sourceMap": true,
    "outDir":"dist/"
  },

I mentioned this in the other thread, but if there is enough support, I wouldn't mind building a halfway measure with ES6. You'd find fewer and fewer people knowledgeable in CoffeeScript that can help maintain a project targeting a technology that is so new(RAML) as time progresses.

#57

[ghost]

@oshalygin I agree with your proposed JavaScript instead of CoffeScript / TypeScript approach. It may not perhaps be the best overall approach in the long term, but RAML 1.0 won't get enough traction without these tools working.

[oshalygin]

@janaaronlee
Here's my response in the other thread:
#57 (comment)

This Saturday/Sunday I plan to have a working version(stable). I don't mind helping with a bit of CoffeeScript on abao but that may be limited until I get the rest of the tooling together with the unified docs.

A better solution may just be a module that abao can consume to support RAML 1.0 and have a command line arg(or better yet, read the version via raml-js-parser-1).