mithriljs / mithril-codemods Goto Github PK

Version 0.6.1 of execa just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As execa is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 3.17.1 of eslint just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As eslint is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

https://github.com/tivac/mithril-codemods/blob/master/transforms/m-module/index.js#L9-L12 looks cool & I bet is very useful, should update existing transforms to use it.

Original Source

function() {
    m.redraw.strategy("diff");
}

Tool Output

function() {
    m.redraw.strategy("diff");
}

Expected Output

function() {
    if(m.redraw.stategy) {
        m.redraw.strategy("diff");
    }
}

or

function() {
    console.warn("m.redraw.strategy is DEPRECATED") || m.redraw.strategy("diff");
}

Community health files are stuff like CONTRIBUTING.md, FUNDING.yml, and so on, stuff that normally lives in .github, docs/, or the repo's root. I've added default files for everything on this list of supported file types except for a CONTRIBUTING.md file, as that process varies pretty greatly across repos. For issue templates, there's two templates: one for bugs and one for feature requests. The pull request template and issue templates are each derived from the core project's own core templates but with core-specific stuff omitted.

No action is required on your part, but you may wish to customize these appropriately and/or take other related action in light of this like adding/removing issue templates.

If you have any questions, comments, or concerns, please file an issue and I'd be more than willing to address them.

first run:
job: vnode.state.attrs.job

second run:
job: vnode.state.state.attrs.job

{
    view : function(ctrl, options) {
        ctrl.fooga;
        options.wooga;
    }
}

should become

{
    view : function(vnode) {
        vnode.state.fooga;
        vnode.attrs.wooga;
    }
}

... at least I think so. There's nothing in the migration guide about it and there ought to be.

Original Source

m.route.buildQueryString({ ... })
m.route.parseQueryString("...")

Tool Output

m.route.buildQueryString({ ... })
m.route.parseQueryString("...")

Expected Output

m.buildQueryString({ ... })
m.parseQueryString("...")

All of these links are broken, and need updated to point to next.

Version 3.2.0 of eslint-config-arenanet just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As eslint-config-arenanet is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Original Source

{
    controller : function() {
        // ...
        this.onunload = clear;
    }
}

Tool Output

{
    controller : function() {
        // ...
        this.onunload = clear;
    }
}

Expected Output

{
    controller : function() {
        // ...
    },
    onremove : clear
}

To help automate a better changelog/commit messages across-the-board.

remy/clite@fc36b01

Is a reasonable example of a starting point.

See facebook/jscodeshift#148

For now will do something similar in concept to what https://github.com/avajs/ava-codemods/ is doing and run jscodeshift once per transform against all files.

🤢

Because stuff like this is slipping through a lot.

- config : function(el, init) {
+ onupdate : function(vnode) {
  if(init) {
      return;
  }

- ctrl.form = el;
+ ctrl.form = vnode.dom;

Version 0.13.3 of husky just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As husky is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

m("div", {
    onclick : function() {
        m.redraw.strategy("none");
    }
});

will be rewritten as

m("div", {
    onclick : function() {
        e.redraw = false;
    }
});

which is good, except e is now undefined and the code will break. Will need to add a param if there isn't one.

Version 2.12.0 of validate-commit-msg just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As validate-commit-msg is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Original Source

function foo(ctrl, options) {

}

const comp = {
   view(ctrl, options) {
      return foo(ctrl, options);
   }
};

Tool Output

function foo(vnode) {

}

const comp = {
   view(vnode) {
       return foo(vnode.state, vnode.attrs);
   }
};

Expected Output

function foo(state) {

}

const comp = {
   view(vnode) {
      return foo(vnode.state);
   }
};

Original Source

m("")

Expected Output

m("div")

The original form is arguably a bug, and there's no reason this tool couldn't trivially update that to not be a bug.

Original Source

const m = require("mithril"),
    controller = require("./controller");

module.exports = {
    controller : controller,
    view : () => m("div")
};

Tool Output

const m = require("mithril"),
    controller = require("./controller");

module.exports = {
    controller : controller,
    view : () => m("div")
};

Expected Output

const m = require("mithril"),
    controller = require("./controller");

module.exports = {
    oninit : controller,
    view : () => m("div")
};

Just look at this 🐛

 export default function() {
-    m.route(
-        document.body,
-        prefix("/setup"),
-        keys({
-            "/setup" : setup
-        }, function(value, key) {
-            return prefix(key);
-        })
-    );
+    m.route.set(document.body, prefix("/setup"), keys({
+        "/setup" : setup
+    }, function(value, key) {
+        return prefix(key);
+    }));
 }

Would be nice to be able to identify functions like this.

export function view(ctrl, options) {
    ...
}

Since not only is it named view but it takes the exact two params we'd expect. Taking just ctrl as the first param is probably enough.

http://astexplorer.net/#/gjQK00HsXw

Version 0.6.2 of execa just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As execa is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Because this is odd-looking.

- controller : function(options) {
+ oninit: function(options) {
      var ctrl = this,
-         val  = get(options.field, "attrs.value");
+         val  = get(options.attrs.field, "attrs.value");

-     ctrl.id = id(options);
+     ctrl.id = id(options.attrs);