search

WebThingsIO / thing-url-adapter

Proxy adapter for Web Thing API endpoints
Mozilla Public License 2.0
21 stars 18 forks source link

Addon version upgrade / convert to typescript #110

Open 0815fox opened 2 years ago

0815fox commented 2 years ago

I am about to provide a pull request which upgrades this addon to typescript. Seems to me that the API is based on Version 0.12.0 of gateway-addon-adapter, which was not Typescript back those days. So I have to raise that version as well

Now I got stuck with three questions:

  1. I read

    This should NEVER be included as an add-on dependency

which makes totally sense. However, is the intension to add it as devDependency in order to get ts typings?

  1. For the moment I did so, however, then the question arises: Which version of gateway-addon-node should I refer to? Ignoring all alpha versions I would tend to 1.0.1-0 (which might be alpha as well or what does -0 mean?) So v1.0.0 would be the only remaining non alpha version (which also seems strange).
  2. How does the addon manager know, which interface version the addon complies to? Can't find it in the manifest.
benfrancis commented 2 years ago

I am about to provide a pull request which upgrades this addon to typescript.

"Upgrades" is a matter of opinion ;) Personally I am regretting ever allowing TypeScript into the code base and would rather not add any more, but I may be be alone in holding that view.

The same question came up in https://github.com/WebThingsIO/wot-adapter/pull/9 Maybe @tim-hellhake or @relu91 can provide answers to your questions?

0815fox commented 2 years ago

"Upgrades" is a matter of opinion ;) Personally I am regretting ever allowing TypeScript into the code base and would rather not add any more, but I may be be alone in holding that view.

Well, that this project uses typescript (as opposed to plain javascript) was one of the major reasons for my decision to use and support it. I'am no fan of microsoft but IMO that's the first time they've come up with something really good. Of course I respect your opinion but could you somewhat explain why you came to that conclusion and also how decisions are made in this project.

The same question came up in WebThingsIO/wot-adapter#9 Maybe @tim-hellhake or @relu91 can provide answers to your questions?

Well my opinion about that is, that it is a dev dependency - this also marks that this addon kind of relys on the interfaces exposed by that module.

0815fox commented 2 years ago

Oh, I did not stumble across https://github.com/WebThingsIO/wot-adapter . Having that seen I'm asking my self if it's even worth spending any energy on this adapter.

relu91 commented 2 years ago

The same question came up in WebThingsIO/wot-adapter#9 Maybe @tim-hellhake or @relu91 can provide answers to your questions?

Well my opinion about that is, that it is a dev dependency - this also marks that this addon kind of relys on the interfaces exposed by that module.

As far as understood it's a little bit controversial. The modern approach (i.e., > npm7) suggest using only peerDependencies since it is the right place to express a plug-in -- runtime relationship. However, npm6 does not install automatically peerDependencies and this creates a bunch of problems when releasing and building the plug-in. Since everything here is still npm6 compliance package-lock.json v1 in wot-adapter we are using a safe approach which is basically having gateway-addon both as peerDependency and devDependency. About the version, It depends on which version of the https://github.com/WebThingsIO/gateway/ do you want to target, 1.1.0 is using ^1.0.1-alpha.1

Oh, I did not stumble across https://github.com/WebThingsIO/wot-adapter . Having that seen I'm asking my self if it's even worth spending any energy on this adapter.

Having said the above, we have two choices here:

  1. Keep maintaining this adapter as a legacy to interact with old web things implementations.
  2. Support legacy web things in wot-adapter

Personally, I feel like it still makes sense to keep maintaining this adapter as introducing legacy logic in wot-adapter feels dirty to me. Therefore, translating to TS might help keep the entire code base type safe and detect bugs at compile time. But I think the final decision here is Ben's and Tim's.

benfrancis commented 2 years ago

@0815fox wrote:

could you somewhat explain why you came to that conclusion and also how decisions are made in this project.

This is not really the place for an in-depth discussion about TypeScript (my bad, sorry), that's a discussion for elsewhere. My initial skepticism about TypeScript has only be reinforced by my experience of using it for the last few months, for me it causes more problems than it solves. I think the ship has sailed regarding TypeScript on the back end of WebThings Gateway though.

The current governance process for WebThings is outlined here.

@relu91 wrote:

  1. Keep maintaining this adapter as a legacy to interact with old web things implementations.

I also prefer this option, and FWIW I expect this adapter to continue to exist for some time. As a minimum until all the WebThings Framework libraries are made W3C compliant.