Consider Dropping Legacy Support for Node JS 0.10.x

[eriktrom]

cc @indexzero -

opening a discussion - our users are our lifeline and they're asking for es6 - which is of course a legit ask - but then something dawned on me, if we don't remain relevant to them, we can't help them go through the ARM transition and from personal experience there it's already affecting people using even python for their math class and OSS contributors to system level languages trying to fix bugs on windows, its something I'm excited about it didn't really register that if we don't let people contribute es6 module syntax changes b/c we support legacy node then when it comes time fix syscall errors on ARM on all the operating systems, were not really helping out, we might be making it worse by not being there for them, all 10 million downloads of them (how is that possible - were a dep of a dep of multiple js frontend libs, firebase-tools and whomever builds on top of those more well known tools).

in short I think we need to drop legacy support for node so that we don't keep closing issues that people are excited about contributing to portfinder, so that, when we need our users syscall errors on ARM and x86 for all operating systems, some of which are not even close to stable (system level programming on windows with an ARM chip is something I literally seen cries for help, like "anyone who knows windows and ARM we'll pay you, and we work at Microsoft but can't find help, and can't fix this OSS bug" or "I can't do my math homework on this surface my parents bought me" (they no longer sell those but they did and will again - perhaps 2023 but who knows).

Point being, I want to be there for the community on this one. It's been a while since we've seen this kind of change, actually, I don't think we've ever seen this kind of change at this rate or even close to it in any industry let alone programming - so I thought I'd file a meta ticket, get your thoughts (and insight, experience, perspective) and go from there.

Last note, if we don't drop node legacy we can't help them either. As I know we've both seen (separately) - some enterprise frontend stacks have multiple frameworks across many teams and are still using old versions of node b/c its just tooling and companies that are not forward thinking tend not to spend money until they have to - when they start using arm, legacy node will throw different sycall errors anyway, so in short, we need to progressive js frontend, hot and shiny, always upgrading community to tell us what errors they get when the inevitably hit them, this will allow us to support x86 and ARM for libraries built and maintained by facebook and google in order to allow people to program their react apps on apple and windows - without me having to have access to every operating system on every arch - just to reproduce a bug when react app wont start someday.

This is our community, we need them, they need us, I keep closing es6 bugs and this afternoon I reflected and realized if I keep doing that, more work for everyone, the whole philosophy of OSS breaks down during a time of transition and were one of the lowest level and highly installed libraries on npm.

I'm glad I told someone I couldn't merge their es6 module pr today and then realized in doing so I lost someone who might provide me with the syscall on a random OS running ARM, or more likely, a windows user trying to just learn react walks away from programming forever b/c no one knows what errors to catch because that was us, and we drove away the people trying new things before we could get their error messages that'll help everyone else.

screenshot of above the fold dependents of portfinder, note the first one is responsible or im not sure but perhaps half of the 10 million weekly downloads - and portfinder only downloads when you first install create-react-app the first time, unless you wipe ur node modules, which isn't the case, given the only library downloaded more than portfinder is create-react-app - which downloads webpack-dev-server which downloads portfinder. Not to mention ember-cli, firebase-tools, and whatever else is built on the rest of the other 1695 dependents, "depending" on us for stability. Dare I say, if we don't keep track of this, through our users, I'm not sure who will or how long it'll take them to catch all x86 and ARM syscall errors on all operating systems, of which you can only run a vm for if you have that arch type.

The reason I feel strongly about this, is also historical. When WSL came out, its our community that made dev on windows possible for a lot of frameworks. When touchbar came out, its our users who told us there was an issue - one that I couldn't fix without a touchbar laptop. Amplify that by adding two completely different architectures and new operating systems that are emulating x86 (rosetta2) and I can't imagine what will happen if we don't let people start merging stuff they're into like es6 modules starting like yesterday...

Per our async "we were thinking the same thing when we both coincidently opened tickets to have a discussion with each our org about what to merge and what not to merge to preserve stability" - let's now update that discussion to preserve community by merging new features so we can preserve stability by having a community when arm on especially windows starts to throw errors I am certain will occur, at least if they don't then that would be idiosyncratic to say the least, after what I've seen come through this lib since I started maintaining it. Last thought - its also the only way for enterprise users will be able to run old versions of node with their old tooling on new computers that seem to cycle every 2 years within enterprise corporations I've worked with anyway.

I think i just talked myself into it, what are your thoughts @indexzero. Also, I'm going to cc a couple people from the ember community as they have insight into tc39 and microsoft and maintain a progressive and highly performant js framework (that maybe lost a popularity contest to facebook but nonetheless put you and I in touch), and whom I consider mentors so I value their opinion and would like to hear it, specifically, @stefanpenner the most prolific contributor I've ever seen come across my screen and the face of ember, the well connected, well spoken, react community disruptor and microsoft employee, @tomdale) (I may be dating myself if they've changed companies lol).

---

what do ya'll think - I think I should go back and merge a number of es6 pr's I've said no to and drop node 0.10.x so that this huge symbiotic community doesn't suffer when, just like WSL for windows and touchbar for mac, the errors flood in as soon as the law of large numbers kicks in, at which point we'll have no community of early adopters to have told us what those errors are before the rest of the community starts hitting them, which will cause frameworks to scramble to find a solution when right now, at this moment we can get the early adopters back (i've said no so many times, that today someone rightly said why don't you just freeze the lib so people don't get the wrong idea and can start looking or building another solution to their portfinding needs that yes at first might be all about es6 modules but really in the end will become an issue when probably Microsoft (historically in this repo) puts an ARM chip inside next year's or the year after that's surface pro and we run into the WSL error scenario, magnified and without eager people willing to hop into their debugger to tell me what the syscall error actually is, which is how WSL got fixed and how touchbar got fixed - how ubuntu with ipv6 turned off for some users got fixed - how everything has gotten fixed - how ::1 got fixed, which is how i got involved in this to begin with --

tldr - how should I proceed now that I've talked myself into the fact that if we do nothing, I need to put tell the world that portfinder is no longer maintained - which from what i've seen from many teams, doesn't seem to matter, people just let the yellow deprecation warnings go on until the day their dev server stops working and were back to square 1, we or at least I, know its coming right here and now.

Our community(pic below), 10 million downloads a week - shouldn't just be left in the dark - so suggestions are very welcome (ps thanks @stefanpenner ahead of time, I know you have other things going these days, even a link to what you did at some point in the past that is similar to this scenario is enough to give me confidence to think about this one way or the other, as at the moment, the only action I feel comfortable taking is pinging the only 3 people who can give me advice on what just came to my pre-frontal cortex's attention...

(so many words, ehh. sorry, i dont have a summarized version b/c I just realized this today, and why speculate alone when ya'll have way more experience with this kind of thing - even if none of us have experience with the ARM transition, at least ya'll can help me think about this one way vs another, i'll forgo speculating and just ask, how mature of me, lol)

again thanks in advance for even a one liner suggestion

[MasterOdin]

Two of the tools listed on the above list (webpack-dev-server, serverless-offline) have removed portfinder as dependencies since this post was made.

Drop support for old versions of node (0.10 support ended almost 5 years before the OP was made in Oct 2016), make a new major release, and incorporate more modern JS practices. Hell, 4 of the 5 dependencies of portfinder can never be upgraded to the next major version as the minimum shared node target is node 6.

I'm glad I told someone I couldn't merge their es6 module pr today

Which has forced firebase-cli to have a shim in their codebase:

// Typescript emulates modules, which have constant exports. We can
// overcome this by casting to any
// TODO fix after https://github.com/http-party/node-portfinder/pull/115
(portfinder as unknown as { basePort: number }).basePort = 9005;

At some point this may break and then they too will be forced off portfinder (though the PR would have fixed an es6 issue while totally not affecting anyone not using es6). Being conservative on a dependency that's used a lot is great, but holding back all progress in the name of some unnamed enterprise corporations that refuses to update their tech stack (and who also would then happily keep using portfinder 1 while the community moves on to portfinder 2) is baffling, unless they're paying you money to maintain that support, though something tells me these companies are spending the bare minimum on their software, until they have to then set a bunch of money on fire rewriting everything once whatever stack they use isn't even installable on a new version of OS as even companies that give LTS policies in the decade+ end support for old things.

[eriktrom]

@MasterOdin - you are correct - I completely agree. I don't own the project, but I figure a year (to the date) seems sufficient to move ahead with autonomy. :)

Updating, will release tomorrow most likely sometime.

Thanks @MasterOdin for your feedback and comment above, from 4 days prior to 365 days of no response :)

[MasterOdin]

Hah, what lucky timing, as I really only made the post as I stumbled onto it 4 days ago when I was upgrading the version of portfinder in my employer's codebase and went looking to see what had changed between the two versions.

Having cut my teeth on IE compatibility, I have a burning passion for advocating to drop support for very old platforms if it stands in the way of making things better, and easier to maintain (which I'd say Node 6+ in adopting ES2015 and ES2016 features).

[eriktrom]

closed by #137

[MasterOdin]

I'm not sure this issue was resolved by #137, given that the library's minimal support is still node 0.12. I mean, I guess technically support for node 0.10 was dropped a while back, but I'd consider this issue covering dropping all EOL old versions.

It's not clear to me if you'd support having a v2 of this package that drops all node versions under some version (12?), and then could proceed to complete #131 in removing mkdirp completely, as well as would allow for making nicer the test cleanup code I added in #135.

[MasterOdin]

Dropping old versions of node would also allow some niceties like combining getPort into a single function with dual signature:

export function getPort(callback: PortfinderCallback): void;
export function getPort(options: PortFinderOptions, callback: PortfinderCallback): void;
export function getPort(options?: PortFinderOptions): Promise<number>;

which is similar to how most other libraries I've used support a function that has both a callback and a promise based interface as wouldn't need to worry about promises not being available.