v5.x does not run in ioBroker.backitup

[simatec]

I can't get the v5.x to run in ioBroker.backitup.
How exactly must the v5 now be included in the package.json?

https://github.com/simatec/ioBroker.backitup/blob/master/package.json

Do I still need additional packages?

I don't really understand the instructions....

[simatec]

I did some more research. Unfortunately, we can no longer include the package for ioBroker.

Is it possible to continue to offer the package without ESM?

ioBroker.backitup is quite popular and has around 70,000 installations.

About 40% of your package downloads come through ioBroker.backitup and I would be very happy if you would support it.

[susnux]

You can use something like babel to transpile.

[simatec]

Personally, I don't think that's the best way to go. Direct support would be better here...

[perry-mitchell]

ESM has been around for quite a long time, and many packages are exclusively ESM only now. Maintaining a codebase that supports both is rough, and for this project I decided that I didn't want to run both if I could avoid it.

Are you sure you won't consider upgrading your project to support ESM? At some stage you'll come across more and more packages that will prevent you from using them if you wish to be on the latest stable versions. I'm surprised if you haven't seen more of this outside of just this project.

[Apollon77]

Yes ESM is around since long but in my eyes not really used beside in browsers. I think the majority of node.js projects still use CommonJS. In fact t is a flavour topic (again), but a big incompatible change because you can not easiely "Just use a package" (ok you can when you change to an async "require" way).
In fact mainly some "developers with packages with many users, e.g. sindresorhus, decided to do the full cut and update all their packages as "ESM only" ... but thats still far away from" many" - at least in my feeling.

In fact because of such strong decisions also other devs started projects like https://github.com/esm2cjs that rebuild the packages to allow an more easy use ;-)

Especially with Typescript it is easy to publish a package with both and you use TS, so (also just out of personal iterest) what exactly is the "rought" part to maintain it? Yes you need to get the exports and tsconfigs for builing right (once) ... then nothing is needed and you make the life of the library users more simple.
Sure, if you rely also on packages that switched to such a are ESM-only-approach then I understand the decision because then it is easier. No idea if this is the case for webdav-client.

In fact it is clearly your decision what you do with your package.

[perry-mitchell]

I think the majority of node.js projects still use CommonJS

This is true, but it's shrinking as time goes by. It's inevitable that we end up with ESM as the default. Node and browsers will move to support the ECMAscript standard, which has ESM as its decided module handling system.

big incompatible change because you can not easiely "Just use a package"

You can, so long as you just set the module type in package.json. It no longer requires a flag on the CLI of new node versions. As time goes by, the default that npm creates will also be "module", so soon CJS will be what you need to spend effort in configuring.

Sure, if you rely also on packages that switched to such a are ESM-only-approach

This library does, because of many packages going that way. Staying current for stability, support and security is important to me, and that requires embracing ESM as a consumer. This is far easier when downstreams like this library also use ESM, as you said.

It also helps the community, despite your suggestion to the contrary, in switching to modern practices being embraced by the JS community. The more packages that move across now will nudge other consumers into doing the same.. a ripple effect for support of the new standard. This is exactly what sindre did, and while it annoyed the hell out of me when I discovered what it meant, I've since come to appreciate it and understand the decision. It is a pain, but once you get used to the setup it certainly becomes painless.

While I honestly, really want to help downstream libraries use webdav to achieve their goals, I do also want to contribute to steering the community in the right direction. ESM isn't a fad, and it isn't going away.. At some stage a package will take one of the 2 following paths:

• Obsolescence
• ESM and modern practices

In fact it is clearly your decision what you do with your package.

While this is true, the same with your package, I'm not commenting on these points just to harangue you.. I genuinely want to come to some sort of understanding here. And while it disappoints me that not everyone yet sees the migration to ESM as an important one, I do get that it's hard to change some larger libraries, such as ioBroker. I face similar challenges at work with private packages, but most of those have been changed now and the workflow is no different or more difficult (arguably it's simpler, because we no longer get stuck when updating packages).

I will consider adding a CJS build as I did for ulidx.. but no guarantee on when. I would consider a PR if someone submits one.

[Apollon77]

Thank you,

In fact I completely understand your thoughts and opinion.

For us the "problem" is that we simply can not change that easy and short term. The plugin system of iobroker and the over 450 plugins is kind of an sub-ecosystem and we can not break that. So for us that change will surely come and will be a heavy lifting ... but we are not there yet.

So yes once you accept it it gets easier. But the reality is mostly not that easy. Maybe @simatec can change to a Async import. Lets see.

On the other hand - and this is personal note (not "against you", more in general for the approach some devs "drive" esm transition) also from all my 20+ years professional experience: while I understand that the future needs to come and needs to be supported I will never ever understand forced approached because in my eyes they are kind of unfair and remove decision options. And I personally hate if someone else wants to drive my decisions or forces them into a certain direction. ;-) especially if it in fact not "needed" to be such forcing because there are normal options - and transition processes for me works best if people have the choice when they are ready for the change ...

[perry-mitchell]

If the community were to just wait for everyone to transition, we never would, and would end up with a fractured platform that would only serve to hinder progress. Well, more fractured than it already is :). I think the transition has been very generous, slow going and actually somewhat quite understanding. A lot of people have converted to hybrid libraries as I mentioned, with a few of mine also being in such a state.

I'll do my best to get webdav into that position as well.. just no guarantee on time as I said.