Plugin developers, stay alert. We are refactoring Windy.com client codes to typescript!

vicb

@ivo I somehow missed this post before.

huge fan of TS here, I'm super happy with this move.

vicb

@marekd Hey what is no clear to me is how the changes will be deployed.

i.e.

Will W.$ start to break when the new version is released ?
Can we update to use W.utils.$ now ? If not will W.$ be an alias in the next few version so that the plugins do not break on the release day ?
Would there be a way for windy to offer a staging of the new version before the release so that we can test/update the plugins before ?

Thanks.

marekd

Hey @vicb. Yes, it will break plugins at the moment of release. I would recommend to use e.g:

const $ = W.$ || W.utils.$;

This should work on current and also future version of the client.

Public test version for plugin developers is a great idea! We will figure it out somehow for the next iteration :-) Send me a PM if you need it now, for the current release.

vicb

@marekd One thing that could be great too is to be able to load different js files according to windy version. That should be easy to implement by adding an extra field to the package.json of the plugin.

With that plus a public test version you can prevent plugins from breaking when the API has a BC break.

vicb

I have updated my plugin to use:

const $ = W.require("utils").$ || W.require("$");

Note that the order is important here as W.require("$") would crash the next version if first in the expression (as the module is going away).

That should be the only required change for my plugin.

rittels

Hi @vicb

How would write the package.json? how about:

"old_windy_version":{"33.0.0": "path_to_other.js"},
"main": "dist/plugin.js"

So if the version < 33.0.0, use path_to_other.js, else use main.

vicb

@rittels

I was actually thinking the other way around:

main would be the default (i.e. dist/plugin.js)

and main_updates would be your old_windy_version but if the version is >= 33.0.0 then the other js would be loaded instead.

Algo would be: use the highest version from main_updates that is less or equal to current windy API version and use main if none found.

But I guess both would work

marekd

@vicb Thanks to @rittels there will be support in a next windy version for specific loading as you discribed in your last post. Just for to be sure I copy-paste the logic of finding the version:

let path = '';
if (json && json.main_updates) {
    const mainUpdates = json.main_updates;
    const windyVersion = ver2num(rs.version);
    let min = Infinity;
    for (const version in mainUpdates) {
        const diff = windyVersion - ver2num(version);
        if (diff >= 0 && diff < min) {
            min = diff;
            path = '/' + mainUpdates[version];
        }
    }
}
// ...
// load `${pluginRootUrl}${path}`

Feel free to suggest anything you need for surviving this crazy period of windy refactoring :-) It is easy to change the logic while it is in a dev branch.

vicb

@marekd said in Plugin developers, stay alert. We are refactoring Windy.com client codes to typescript!:

windyVersion

Looks great.
Thanks and good luck with the refactoring.

marekd

@jakubvrana @rittels @vicb Hey guys, public beta is available and a lot of breaking changes are inside. Please, see this post for more details:
https://community.windy.com/topic/18358/v34-0-0

We would like to release a new version to production at the end of next week, or the beginning of the week after that.

We apologize for any complications and hope to complete the refactor soon. Thank you for all your work, we appreciate it!

marekd

@rittels @jakubvrana @vicb If you have accessed the property bounds of any model/product (eg. W.products.iconEu.bounds), please change your codes.

We added into client version 34 support for general polygons, so instead of { west, east, north, south } object it is an array of [lat, lon] arrays: [[lat, lon], [lat, lon], ...].

All inner methods using bounds still have the same interface, only this property has been changed.