node 4, babel and wreck

[robertkowalski]

heya,

this is an issue to discuss Node 4 as a requirement for nmo and the future of babel and wreck. Wreck uses ES6 features, but does not use babel, making it very hard to use without having installed Node 4 or 5. According to the Wreck developers they want to push Node 4 adoption with this move.

I keep thinking about node >= 4 as a requirement for nmo at least until next year, when Node 0.10 and Node 0.12 support is officially dropped (I think Summer 2016). The reason is that many CouchDB developers are not necessary Node.js developers, and therefore use an old Node version. When talking to people that don't use Node that much it turns out that they also usually have their installations messed up, making it very hard for them to upgrade a system they don't understand. I even know some JavaScript developers which install all their packages with sudo, but I am mostly worried about people that use Node just as a platform to run a few scripts once a week, and are mainly using PHP and Clojure or Ruby.

This is somehow contrary to nmo's paradigm to provide as less friction as possible to the user.

Another thing that came into my mind if we just support the latest versions of Node.js there is not much need for Babel any more

and now?

Ideas that came to my mind:

• jump on the Wreck bandwagon, and remove babel with it. This makes our development easier as we don't have to transpile any more
• move from Wreck to request and support all currently officially supported Node versions again. Wreck was introduced when all dependencies where still bundled and every dep and subdep had their own section in the license file, which is not the case any more. I think request had one dependency which did not had a license file, but I think it got fixed recently (Publish latest version request/caseless#23)
• revert Wreck to the old version. don't update if they don't support ES5. mark as tech debt and either upgrade in summer 2016 when Node 0.12 and Node 0.10 see their end of life or move to another library when we got time

What do you think?

[garrensmith]

I think we should move to request. I agree that not everyone will have node 4 installed at this point and I think it would be better to support machines with a default older node installed.

Maybe we should create a wrapper object around all our http requests so that underneath it doesn't really matter what library we are using. Then each command can just import our http lib with which ever functions they need.

[robertkowalski]

I started it today but run into a lot of yak shaving with broken tests.

it also looks like we have a few tests that pass, but should fail (i.e. .catch not added or wrongly used), because when i replace parts of nemo with request they fail because they make no sense

we don't gain anything from introducing the major breaking changes from the new Wreck at least I am not aware of a reason, so i opened a pr which reverts wreck to an older version.

[tmpfs]

I disagree with supporting older versions of node, I think the cleaner solution is to move to requiring node >= 4. Older versions of node will be deprecated as mentioned above and it is trivial to switch between versions using nvm.

Removing babel would be a massive plus for development. Wreck is a new library to me and I don't know why it was picked over request (I assume there is a reason) but it would seem illogical to replace it at this stage.

The reason is that many CouchDB developers are not necessary Node.js developers, and therefore use an old Node version.

I understand the concern but at some point it is better to encourage people to either upgrade or use nvm, sooner rather than later I think.

[robertkowalski]

These are the versions of Node people used in November to download packages from the registry:

https://docs.google.com/spreadsheets/d/1AY1GbB1WGix4CZXY6L-6QEFZlArN1C_Ew3jMMWQ1XpQ/edit#gid=0

@tmpfs I agree with you when I wear my hat as a Node.js contributor. We should push people to use the latest Nodejs versions and teach them that tools like nvm are great.

With my hat on as nmo maintainer I have a different opinion. nmo's goal is to provide the best user experience for all users that set up and work with CouchDB. I spent a lot of time to remove all friction for them to enable them to get their jobs done as easy and fast as possible. The mission of nmo is to be the tool that enables them to get their job done - with no friction.

nmo users want to get specific tasks done with their CouchDB clusters. This does not mean they are interested in Node.js, clean code, ES6 or setting up a top notch Node.js environment. And I can't say I would expect them to care. They want to set up a cluster, maybe because their boss told them, not update their Node.js. They don't want to read documentation how to setup Node to find out how it works with the tool they just want to give a spin in their lunch break.

What is the path where we attract the most users and provide the most value to people that want to administrate their CouchDB right now? Let's take a look on two paths for Node.js 0.12 users, which is still maintained and not deprecated by the foundation:

Path a) We throw syntax errors when they try to use nmo they have never seen. 2 of 10 persons leave. The rest googles for it, does not find a solution. 1 person leaves. The rest finds a document that states they need Nodejs. Two people don't care enough and just use curl. The remaining users install Nodde, reinstall nmo and can set up a replication after 25 minutes.

Path b) They install nmo and start the replication after 1 minute.

Because of these reasons earlier deprecation of legacy Node.js version which are still officially supported is a topic which should be discussed at the foundation.

If we don't support still maintained Node versions in nmo any more we are doing the same like the Wreck maintainers and push the problem down the chain. For me here at nmo the Wreck update already costs a lot of time - time I would have loved to spent on feature development for nmo, so I propose to revert back to the older version of Wreck and phase it out in the future because of their upgrade policies. There was no real need to upgrade Wreck to ES6 for them without transpiling the code or to just wait a 3/4 year. They just cause a lot of trouble and eat a lot of time from us all.

[tmpfs]

Thanks for the detailed response. I am happy to support your decision, lock down the Wreck version :)

If we are all in agreement on this then that we aim to support the legacy versions of node and lock down the Wreck version then I can start to investigate some of the outstanding issues.

I am doing some housekeeping on other projects this week but feel free to raise and assign issues to me and I'll pick them up.

[robertkowalski]

@tmpfs feel free to work on whatever you like! 😄

if you feel unsure if you should spend many hours upfront feel free to present the idea and get some feedback. you can also take an issue from jira if you like. we usually hang out on freenode, but chatting on github via issues et al is also fine.

the most important thing is that everyone involved has fun :)

[tmpfs]

Great thanks! Just don't want to collide with what other people decide to pick up ;)

Little busy with an idea this week, but I'll try to get some contributions in next week.

Fun and games indeed :)

[robertkowalski]

fixed