Skip to content

Generate warnings for code that Lebab does not transform #136

@nene

Description

@nene

When Lebab fails to transform some piece of code, the user will be left puzzled over whether it's a bug in Lebab or whether the particular code is ignored for a reason.

There are lots of cases where we cannot automatically perform the transformation:

// arrow: not converted to arrow-function because it's using this
array.forEach(function(el) { return this.x + el; });

// let: Not converted to let because let declarations cannot be repeated
var x = initial;
var x += offset;
return x;

// obj-method: Not converted to method foo() because recursive call of foo() would not work
var object = {
  foo: function foo() {
    foo();
  }
};

// commonjs: Not converted to import because imports can not be nested inside blocks
if (foo) {
  var foo = require("foolib");
}

// class: Not converted to class, because ES6 class syntax does not support non-function properties
function MyClass(prop) {
  this.prop = prop;
}
MyClass.prototype.maxCount = 10;

When running Lebab I'd like to get a list of warnings like so:

$ lebab -t commonjs,let input.js -o output.js
 3:1   warning  imports cannot be nested  (commonjs)
 8:4   warning  let declarations cannot be repeated  (let)
10:4   warning  let declarations cannot be repeated  (let)

So I could go in to these files after running Lebab to perform the remaining conversions manually.

Implementation

I see two alternative program-level API-s for these warnings.

const {code, warnings} = transformer.transform(source);

This first version has the drawback that it breaks the current API and is slightly more inconvenient to use than the current API. However, some other tools like recast provide a similar return value. And if we're going to break the API anyway with Lebab 2.0, then we don't need to worry about this additional breaking.

const code = transformer.transform(source, (warning) => console.log(warning));

This version avoids breaking the API, but it is actually more inconvenient to use when you do want to use the warnings. Initially I quite like this approach, but after toying around with code a bit, I'm now leaning towards the other version.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions