hueniverse
commented
6 years ago I'd start by saying that this is more about how people feel about using a version that is not the latest vs. any actual issue with it. You can continue to use all the module versions used by hapi v16 for as long as we support it (which at this time is at least until April 2018 when v6 goes out of LTS). Even then I doubt it will take much effort to keep a working version around because these modules are very stable.
In order for us to keep the master of these modules compatible for older versions of node we will need to both introduce new modules (e.g. hoek now has async/await utilities we use) and have different styles for writing tests (and potentially different test runners). It means supporting both callbacks and promises which is messy and inefficient. Also, it means constantly checking which feature of JS we can and cannot use. Not having to ever use arguments again is a big win - and that's in older hoek versions.
If this was an actual problem, if we just made a decision to not backport some critical fix, then sure - your argument would be valid. But for now, it really isn't.
I should also point out that the numbers you quote above for non-hapi downloads are silly. If you removed hawk from request, these numbers will go way down to hapi/joi levels. These modules are pretty much used exclusively by hapi users as far as the numbers go.
So - my suggested solution is that as long as we actively support the last node v4 versions of these modules, you just use them the same way. If we get to a point where we no longer maintain the hapi v16 world, we could discuss what's the best step at that time.
If you still feel uncomfortable about this, you are free to fork, but in practice, the effort will be pretty much the same.
mcollina
The Hapi ecosystem built a lot of extremely useful and powerful utility modules, which are used way beyond the Hapi ecosystem. As an example, boom and hoek are downloaded ~20 millions times per month, vs 400 thousands of Hapi. Those modules are extremely popular and the ecosystem will benefit from not being left behind. I know you are planning to support the current version as LTS for some time, but the ecosystem benefits from up-to-date stable modules that runs along all the supported node versions.
Node 4 will be out of maintenance on April 2018, while Node 6 is supported until April 2019. Node 6 is active LTS (which means features can be backported if possible), and it has still 1 and a half year of support from the Node core team.
(shot is primarly a Hapi dependency but it is the best at what it does, and not being able to use the latest and the greatest in my modules if I want to support all the node versions makes me sad).
I know that supporting old versions of node is hard and it is more work, and I respect your decision regarding time spent in maintenance. I am used to support node versions for a very long timeframe which is way beyond what is sensible (readable-stream still works on Node 0.6), and I know how much hard work that entails.
I think moving 8+ for Hapi is a good decision, and I totally support it. I am worried about the porting time, but it would probably be ok. I would not do it for my modules, mainly because I love callbacks as the primary way I am coding things. In any case, moving to 8+ is a good sign to the community as async/away is easier to read and it is fast: I have some benchmarks that shows that the performance is equal or close enough to callback-based applications.
I kindly ask if it is possible to revert this decision regarding boom and hoek, and support these two modules for all the node versions until they are maintained by Node core. Shot is in essence an Hapi dependency and I would love if it gets more support, but it might be that the maintenance burden makes it too hard. There might be other popular modules maintained by the Hapi community that I know nothing about, so this reasoning might be extended to others.
(This was briefly discussed in https://github.com/hapijs/boom/issues/166#issuecomment-332310947).