Unable to specify custom parser options when using riot.compile #64

joepie91 opened this Issue Apr 15, 2016 · 3 comments


None yet

3 participants


While the _compileJS method accepts parserOpts as a fourth argument, there's no way to specify these when using riot.compile() (as opposed to riot.js(), where it is possible to do so).

The specific usecase where I'm finding this to be an issue: I'm currently working on a project that uses Webpack + Riot + Babel, but the Babel settings for Riot (via riotjs-loader) have to be different from those for babel-node when running the server application. Namely, babel-node uses the es2015-node preset, whereas Riot needs the es2015-riot preset.

Right now, there's no way for me to specify a custom preset in the Riot parser options on a project-wide basis, only for each component individually via an options tag (which is also broken, per #63). This means that it uses the .babelrc, which tries to use es2015-node and consequently fails on top-level this.

My use of riotjs-loader means that I also have no control over which Riot compiler method is being called, and so I'm stuck with riot.compile() and can't eg. patch in something with riot.js(). Essentially, it's impossible for me at this stage to successfully compile my code.

This would only be an API addition (and corresponding documentation fixes), something along the lines of:

riot.compile(source, {
    parserOptions: {
        js: {
            presets: ["es2015-riot"]

You can override the default riot parsers by using our riot-cli and a config file http://riotjs.com/guide/compiler/#es6-config-file I strongly recommend it


riot-cli is not an option, as this is part of a build pipeline. It's possible to override the parser in the riotjs-loader and merge in options using a wrapper method, but this is quite hacky and unintuitive, and really shouldn't be necessary for something like this (which is already 90% implemented anyway, and wouldn't break compatibility).


right, the patch should be really easy

@aMarCruz aMarCruz self-assigned this Apr 25, 2016
@GianlucaGuarini GianlucaGuarini added a commit that closed this issue May 5, 2016
@GianlucaGuarini GianlucaGuarini closes #64 124e620
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment