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

marekd

In a next version of client (31.x.x -> 32.0.0), there will be some breaking changes. Please, be sure you update your code to stay compatible. We plan to release in approximately 14 days. We would recommend you to support both the current and planned versions to keep your plugins without downtime.

picker is moved from rootScope to store under the key pickerLocation
glParticlesOn property is moved from rootScope to store
You should not be affected with this change, but just for the case you use modules in an unusual way: @windy/detectDevice, @windy/rootScope and @windy/utils use named exports instead of default export

All planned changes are due to the rewriting into typescript. Thanks for your work, patience and your support.

rittels

@jakubvrana , @vicb, @johnckealy, @mhaberler, @UnderSampled, @jacobsjo, @kbsali, @Okocedion

There has been an important change in importing a .mjs file in the windy plugins. Plugins importing from a .mjs file are currently broken until updated.

The https://github.com/windycom/windy-plugins repository has been updated to reflect this. The change is in the ./dev/mjs2js.js file.

Specifically the .mjs module should be structured like this, once compiled into the plugin.js file:

W.define('windy-plugin-examples/soundingGraph', ['overlays', 'rootScope', 'store', '$', 'utils', 'map', 'windy-plugin-examples/soundingUtils'], function (__exports, overlays, rs, store, $, _, map, sUtils) {
    ...
    ...
    __exports["default"] = {
        load: load,
        init: init
   };
});

The __exports, is added,
and __exports["default"] replaces return {load:load, ... } .

Also the plugin-data-loader can be imported into the .mjs file like this: @windy/plugins/plugin-data-loader. (Previously you had to say @windy/@plugins..... in the mjs file).

I also added an example to show how the bottomSlider works in the mobile browser.

marekd

Guys, migration to TypeScript continues. We will release a new version of the client next week. There are some breaking changes. Please, ensure your plugins suit these changes:

module W.$ has been moved as a method to W.utils.$
path format of products[model].calendar.paths has been changed to format eg. 2021081001 (no slashes)
W.store.get can throw an exception if property does not exist
(W.trans exports all strings under named export t)

Thanks @rittels for all his help and beta testing new client with plugins! We expect there will be at least 2 more releases before all core components have been migrated. Sorry for all the complications, but we have to pay this technoligical debt :-) Thanks! We are trying with @ivo to do our best to make the migration smooth as much as it is possible, but some pain is inevitable :-)

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.