[CLOSED] v39.0.0

vicb

@marekd
Would be nice if you can update https://github.com/windycom/windy-plugins when there are breaking changes.

First it would help us know what the breaking changes are and also how to support both pre and post breaking changes which is probably the trickiest thing.

vicb

you use only import { anything } from '@windy/someModule for the future compatibility

Do you have typings?

vicb

I have done a lot of reverse engineering in the past to get my plugin to work.

I really think one important thing for windy is to publish a clearer API. There is honestly nothing actionable from the breaking changes description above. Part of if might be that I never opt-in the hacky plugin built system.

But yeah the bare minimum would be to have examples of plugins working with 39+.

https://community.windy.com/topic/22448/opening-a-plugin-at-a-given-location-does-not-work-any-more/13 has been broken/undocumented for a while. Would be nice to get some update.

marekd

@vicb I definitely agree, and we apologize for being so slack. But to be perfectly honest. When we launched plugins, we had an idea of how developers would use it extensively and write plugins for the masses. And in doing so, they would show us what they were missing on Windy. Along with that, we then planned to improve the plugin system, simplify it and make it more acceptable overall for both developers and users. Unfortunately, there are about 5 of you plugin developers and the users of these plugins is quite negligible in proportion with the total traffic. No doubt this is also due to our laxity. So just to explain why this is not a priority for us - for which we apologize again.

We know that we have major shortcomings with the documentation and maintenance of the entire plugin system, but the effort we would have to devote to this is disproportionately large to what it will bring us. And we have a lot of work to do :-) I do not want to say we do not care about plugins and you developers, just that we have to trade time where it does and doesn't make sense to invest it.

We really appreciate everything you do for Windy and we care! This was also the reason why we started working with @rittels, who took care of the whole plugin system and documentation. But as it happens, Chris has his own professional and family life and there is not much time for Windy :-)

But back to the issue, we have whole client i TypeScript and I do not think it would be a problem to post typings if it would help. And updating the documentation on github is definitely a good idea, we will check it out.

marekd

@vicb Or another possibility is that you could join @rittels and help us :-) Just let me know if you are interested.

vicb

@marekd yes I would be interested. I don't have a lot of spare time either but definitely can find some for Windy. Thanks for giving me the opportunity to fix my complaints :)

joseph murphy

Dear App management

Great app.
Will purchase year subscription.

Question - any consideration to including a property line database so one can determine if your on your property or your neighbor's/ public land?

Thank you, joseph

idefix37

@joseph-murphy
Seems possible with
https://community.windy.com/topic/8514/your-map-uploads?_=1684654129113
See many examples in this thread

rittels

@marekd @vicb

I have also been busy the past week, and flying over the weekend.

I have been working on updating the windy-plugins repo in gh, but at the moment it is not working.

https://github.com/rittels/windy-plugins

There is still a bug with loading external plugins in the client.

marekd

@rittels @vicb I have updated examples in plugins repo meanwhile :-) It is v39 branch: https://github.com/windycom/windy-plugins/tree/v39

Also, build system has been changed. Now rollup is used and can be simply modified to developer needs. The crazy obsolete riot architecture with JS inside HTML has been removed as well. Hope it helps.

vicb

@marekd Thanks that will help.

Also my plugin has been using rollup from day 1. I never bought into the former build system.

Let'c chat about how I can help windy when you have time.

rittels

@vicb @marekd

New compiler works well. Thanks Marek.

Small issue on windows system: https://github.com/windycom/windy-plugins/issues/30

The autoloading and querystring passing within the client not working yet. I am working on it.

vicb

@marekd said in v39.0.0:

We removed W.define and W.require. It will work (for backward compatibility for our own plugins), but be sure you use only import { anything } from '@windy/someModule for the future compatibility

Ahah you got me here!

I naively thought that I should have import { anything } from '@windy/someModule; in my code.

But no the code is still transformed at build time.

I guess I will need some more time port my plugin.

When is v39 supposed to be released?

marekd

@vicb We found some issues, so I think we will bugfix them this week. So we would like to release the new version next week. Feel free to ask for help if there is anything I can help with.

vicb

@marekd Are you thinking of releasing the compiler (rollup plugins) as an npm package ? It would be easier for me to first add it to the project and then get updates.

vicb

@vicb

Getting there

I have some feedback about the new compiler:

Why do you have rollup add the call to W.loadPlugin(...) instead of having the plugin dev call it?

Kind of the same questions for both the html and the css. They shouldn't need any special treatment now that you are using rollup. You should be able to remove both buildPluginHtml and buildPluginCss.

Also why would the build system define the meta object?

You can have a look at what I did on the published version of my plugin to use rollup (+existing plugins) without having to build a custom solution.

The only thing that seems useful to me in the new compiler is the rewrite of the imports. But I am not sure I like it either. I preferred to use W.require(...) before than using import ... today which is not a real import.

I'll work on testing/polishing my plugin for v39 now and I hope I can be ready in time.

marekd

@vicb Thanks for the feedback! The only reason was to keep it as compatible as possible with the old version, that is all. We are making things too complicated for the developers already, so we have tried to make it so they do not have to deal with too much around the build.

Feel free to make this package and take care of it, I would be more than happy if someone takes over and I do not have to worry about it.

We will remove W global object and W.require as well in a favor of ESM. So do not use it. That is why the new compiler was created, so that we could prepare it for people beforehand and the codes would work properly with minimal changes.

marekd

BTW, I have merged v39 into master: https://github.com/windycom/windy-plugins

rittels

@vicb @marekd

Beta has been update to include a fix for autoloading the plugins.

Now:
windy.com/plugins/windy-plugin-abc works again.

You can send a querystring like this:
windy.com/plugins/windy-plugin-abc?something=123

You can then access it within the plugin with onopen function:

export const onopen = params => {
    console.log(params.query)
}

You can also send params to another plugin that you may wish to open like this:

broadcast.emit('rqstOpen', pluginName, {query:{ something: 123}} )

Finally: params can also be sent to the dev plugin:
www.windy.com/dev?something=1234&query2=1234.

vicb

@marekd said in v39.0.0:

Feel free to make this package and take care of it, I would be more than happy if someone takes over and I do not have to worry about it.

I'll take a stab when I understand what is coming with "We will remove W global object and W.require as well in a favor of ESM. So do not use it" and when