Express: Should Express 5.0 require a minimum of Node.js 4?

[dougwilson]

This is a discussion regarding having Express 5.0 drop support for Node.js 0.10. One of the reasons for the delay in Express 5.0 was the announcement of the official merging of Node.js and io.js, and we were looking forward to it's outcome to determine what we should do with Express 5.0.

Here at Express, we value very long-lived major versions, allowing users to confidentially build their new server on Express and not have to worry about needing to upgrade across a major, breaking change for years. Express 4.0 has been out for over a year now and Express 3.0 was supported for over 3 years !!

When Express 5.0 comes out, Express 4.x line will continue to be fully supported, delivering our users bug fixes, new features, and more!

To this end, we have been carefully watching io.js/Node.js in relation to Express 5.0 such that we can continue this great support history without accidentally locking us into the past for a long time.

Please share your thoughts here.

[Fishrock123]

Fwiw 0.10 will be EOL'd October 2016, and 0.12 at the end of year, 2016.

The former is already in maintenance mode, and 0.12 will go into maintenance-only next April. 0.12's EOL was cut short due to OpenSSL ending support for 1.0.1 at end-of-year 2016.

More info: https://github.com/nodejs/LTS (Slightly outdated)

I'd personally vote for yes (biased I suppose), and try to encourage a larger move to 4.0.0 sooner than later for users.

[Twipped]

Dropping 0.10 for 5.0 sounds good to me. Express 4 isn't that different, right?

[alanpurple]

+1
drop support for 0.10

[hacksparrow]

Highly in favor of dropping support for 0.10.

[talon]

Open source should move as fast as possible w/ option for sponsored LTS. Drop it.

[aredridel]

What's the cost of not dropping 0.10?

[andineck]

Moving forward to node 4.0 seems more important than supporting 0.10

[dougwilson]

So, just to be clear: Express 5.x dropping support for Node.js 0.10 does not mean _Express_ will drop support for Node.js 0.10. Just like Express 3.x has lived in parallel with Express 4.x for almost 2 years now, Express 4.x will continue to live alongside Express 5.x.

To answer @aredridel , not dropping 0.10 from Express 5.x means that 5.x would be hard-pressed to consume and support various features in the newer V8 and Node.js platform (things like Intl, generators, promises, and more). Because we want to make longtivity promises, this means that once Express 5.0 comes out, an Express 6.0 is unlikely to appear until 1 year or more later, putting it further behind the curve.

Here is a little mock-up support example:

Year             0      1      2      3      4      5      6

Express 3 (0.8 ) +--------------------+
Express 4 (0.10)               +--------------------+
Express 5 (4?  )                      +--------------------+

Typically we'll have 2 active Express majors at a time (more than that gets harder, and the benefit decreases). The idea is that we can then perhaps up the minimum Node.js version with a major, since the previous major will still be around for a long time to come after the release. If you look back at the history of the 3.x line while 4.x has existed, we continued to backport every single new feature from Express 4.x into 3.x that was possible with 3.x's design. We intend to do the same with 4.x/5.x, which means 4.x will keep up; the release of 5.x does not move 4.x into "maintenance mode", either.

[Twipped]

Perhaps a better question to ask is, what does Express gain by dropping 0.10 but not 0.12? Most of the improvements you mention cant adopted until 0.12 is abandoned.

[Fishrock123]

Perhaps a better question to ask is, what does Express gain by dropping 0.10 but not 0.12? Most of the improvements you mention cant adopted until 0.12 is abandoned.

Good point.

If we drop 0.10 we should probably also just drop 0.12.

Stats are that 0.12 doesn't have nearly the usage of 0.10, and is, quite frankly, rather buggy.

[dougwilson]

@ChiperSoft @Fishrock123 , oh, my bad. I do not like to think of 0.12 as even exiting, as there are so many issues with the V8 in that version, it's laughable that people can even use that version of Node.js without getting various illegal instruction errors from corrupted machine code generation.

Yes, this topic assumes that the minimum for Express 5 would be Node.js 4. I have updated the title to correspond :)

[aredridel]

Yeah. I've no real interest in generators, but promises I do -- that said, they work fine on 0.10, so that's not an issue.

Intl is near and dear to my heart, but I'd be intrigued to see what actual plans are before throwing out 0.10.

As it stands, if 0.10 is thrown out, that leaves basically 1.8.7, 2.3.0 and 3.3.0 as the only stable versions. 4.0.0 is not yet. It will be, and it's sure intended to be the future, but I really do value backward compatibility too.

[dougwilson]

Hi @aredridel , I understand the concerns. This is only a discussion at this point without any actual commitment. We are looking to understand what the value is, of course. As for promises, we won't be importing any third-party library to do promises, so we would have to look into how to do promises in 0.10 without a Promise global available.

When we implement any feature, we don't want it to be conditional on the version of Node.js you run on, but available on all supported Node.js versions of Express (thus allowing the user to know that running Express 5.2 on a supported Node..js version, they get all the promised features). Because of this, it makes dropping older versions more important, and hopefully should be possible since Express 4 will be _fully supported, even adding all new possible features from 5 as they come out_ :)

If we decide to bump the minimum version of Express 5, yes, it would delay Express 5 a little longer to ensure that Node.js 4 is in a more stable condition when this occurs.

[aredridel]

Yeah. I'm just chiming in in the conversation.

What's the reason for not using an ES6-compatible shim for promises? It's usually a small dependency, and can be conditional on native not being available.

[Fishrock123]

I just want to note that native promises are still _super_ slow.

[aredridel]

True that.

[dougwilson]

What's the reason for not using an ES6-compatible shim for promises? It's usually a small dependency, and can be conditional on native not being available.

We have tried that on a small scale in koa-related repositories, but it never worked very well, and always ended up better if we only used the global Promise function, which most have changed to doing now.

I just want to note that native promises are still super slow.

And, just to calm everyone down on promises, Express and it's dependencies will continue to exclusively use callback-based APIs. The adoption of promises would be in the public API (for those who choose it use it) as well as accepting promises, for those who choose to do so. As in, the current roadmap is a dual API externally, and a callback-based API internally. This should provide people with promises without any performance penalty for those who choose not to use them.

[aredridel]

Good good.

[Twipped]

Can you clarify what you mean by "use promises"? I was under the impression that just meant accepting a thenable as the return on middleware and routes. That shouldn't require any Promise lib, native or otherwise.

On Sep 14, 2015, at 8:39 AM, Douglas Christopher Wilson [email protected] wrote:

What's the reason for not using an ES6-compatible shim for promises? It's usually a small dependency, and can be conditional on native not being available.

We have tried that on a small scale in koa-related repositories, but it never worked very well, and always ended up better if we only used the global Promise function, which most have changed to doing now.

I just want to note that native promises are still super slow.

And, just to calm everyone down on promises, Express and it's dependencies will continue to exclusively use callback-based APIs. The adoption of promises would be in the public API (for those who choose it use it) as well as accepting promises, for those who choose to do so. As in, the current roadmap is a dual API externally, and a callback-based API internally. This should provide people with promises without any performance penalty for those who choose not to use them.

—
Reply to this email directly or view it on GitHub.

[Twipped]

Requiring Node 4 would be a pretty huge step up, but as long as Express 4 is still maintained I don't think it's a huge problem. Just need to make it very clear that E5 is a future forward version.

[ritch]

@dougwilson What if we adopted Node's LTS Plan? It might not be perfect (and IMO it is very complicated), but at least as a user I only would have to understand a single set of legacy support semantics.

Either way it would be nice to have some documentation (what you should expect) around long-lived major versions.

[OshotOkill]

Since Node 4 & ES6 finally came out I think the next main version of Express should eye for the future to be a new brand of itself, especially the main version have a long lifecycle.

Developers who want to persist in node v0.10 just only to uphold Express 4, and you have already said that would be also maintained after Express 5 realeased. In my opinion node 0.12 should also not to be considered much about compatible in Express 5, but I know that's not realistic.

[ivarprudnikov]

Correct me if I am wrong but compatibility seems to play a bit bigger role here, think third party modules for express. Compatibility would allow quicker uptake of express 5 if it supports node 0.12 for instance as it would not require and would not rely on developers fixing their modules/dependencies to make it compatible with new express. Or would not require searching for new ones.

How would developer know if a module that was used for express 4.0 or 3.0 will work for 5.0? Would I push code to production in this case? I do not know of any automatic tool that could tell me that (idea for greenkeeper.io devs)

[dougwilson]

Hi @ivarprudnikov , nothing in here would make third-party modules not work with Express 5.0. This is simply about a minimum Node.js version for Express. Can you explain how bumping the minimum version of Node.js for Express would break third-party modules for Express? Perhaps I'm missing something critical here?

[ivarprudnikov]

@dougwilson but if module is not compatible with Node > 0.12 ? And the fact that express would require higher (supported) version means there would be additional steps involved in checking if all dependencies work.
In the case of existing fleet of nodes, upgrade would require extensive QA.
In the case when someone creates new apps, one needs to sanity check if all deps (developer is used to) are compatible with higher node version which on the other hand is a positive exercise.

[dougwilson]

Hi @ivarprudnikov are you not able to do this within a timeline of 1 year? Express 4 is not going anywhere for a long time.

[dougwilson]

Also, if you can point me to specific third-party Express modules that do not function with Node.js > 0.12 , that would help a lot.

[ivarprudnikov]

I am not moaning here, sure I could upgrade, it would just take a bit of time.
BTW I just checked passport module and their package.json says it supports node>=0.4, also their site seems to be silent about node v4, but still this is important module which is possibly used by lots of devs. I guess it is going to work with new version of node out of the box, but that alone needs verification.
My 2 cents :)

[dougwilson]

Almost all Express dependencies have "node >= 0.8" or "node >= 0.6" but those are minimum versions. They work just fine with Node.js 4, so just seeing low minimums in package.json gives no insight into working with recent versions. I have personally used passport on Node.js 4 without issue.

My point is that Node.js middleware are typically no where low-level enough to be greatly effected by Node.js versions and I have yet yo hear of a module that does not work.

I'm happy yo include that in the decision if you can point out at least one specific instance that is is an abandoned module.

[dougwilson]

Basically, if a module is not going to work with Express 5.0 right away, it's most likely because it's from an Express change, not because of any Node.js change. For example, a module is going to break with Express 5.0 because it's using an API removed in 5.0 or an API that slightly changed more than anything else.

[listepo]

+1 drop support for Node.js 0.10

[tejasmanohar]

:+1: >= node 4.x.x

[listepo]

@dougwilson >= 4.x.x :+1: or >= LTS versions https://nodejs.org/dist/v4.2.1/

[kevinSuttle]

Great example for what this might look like: https://medium.com/@clayallsopp/your-first-graphql-server-3c766ab4f0a2#.asxjuiq0g

[ximex]

+1 for dropping 0.10 and 0.12

[estliberitas]

@dougwilson :+1: >= node 4.x.x

[webdude21]

drop it like it's hot

[listepo]

Hapi.js now "node": ">=4.0.0"

[jimmywarting]

It's not like we have to support IE6 cuz people refuse to upgrade.
You have the control and can upgrade whenever it's needed.

The only way to move forward with new awesome ES6 classes, generators async/wait and other modern open standards is to invalidate old technology.

Just saying: Dropping it!

[lenovouser]

@jimmywarting express is server-side which means this has nothing to do with IE6 :)

[jasnell]

There's a more practical concern: official support for both v0.10 and v0.12 expires at the end of this year. There will be no further updates to either after Dec 31st.

[Fishrock123]

At this rate, we could probably target Node v6. :)

[dougwilson]

Just because a runtime is not supported doesn't mean Express will stop supporting it at the same time. Express should support what the users need supported, which is the purpose of this discussion, to determine if users have objections or other things. Node.js 5.x still works on Windows XP, even though it stopped being supported almost a year ago now, as an example.

A good example of an objection is that I, myself, cannot use Node.js 4.x at this time in some places until some clouds are upgraded, which should happen sometime this year. It doesn't seem like there are very strong objections to 4+ for Express 5+, so with the fact that Express 4 will be supported for at least a year after Express 5 comes out, Node.js 4 may very well end up as the minimum version.

[Fishrock123]

even though it stopped being supported almost a year ago now, as an example.

[Edited: whoops, mis-understood] Support is dropping in v6, for multiple reasons iirc.

[dougwilson]

even though it stopped being supported almost a year ago now, as an example.

Not quite correct. Support is dropping in v6, for multiple reasons iirc.

I'm well aware of that. That's why I specifically said Node.js 5.x and not just Node.js in general.

[matheuslc]

We have any deal? If I want to contribute to Express 5.x, what's the version of Node that I can use?

[dougwilson]

There has not yet been a compelling "we can't implement feature x without leaving node.js 0.10", so the 5.x line continues to support 0.10 for now.

[blakeembrey]

@dougwilson I think we should look at specifying the minimum node version as 4.0, even if it doesn't impact Express.js core directly. The ecosystem impact is much more important, and it would signal things like the ability for authors to use the global Promise type instead of polyfills, or Object.assign instead of a polyfill, etc. I'm sure there's a lot of authors out there using these things today who don't want to have to deal with node 0.10 support when someone tries to use it. And sure, the module author might be able to specify 4.0 themselves but that's just moving the burden from us to them when it comes to their users.

[matheuslc]

We can improve Express code base with Node.js new features. I think that a project like it have a strong power to push Node forward.

If the only benefit was syntax, we can use Babel to transpile to old versions. What do you think?

[dougwilson]

I mean, simply changing internal syntax to more sugar which has no benefit to users is a net negative benefit to me, because now we are taking away something without any compelling user benefits. The reasons Blake outlines are much better and we can bump 5.0 once something along those lines are needed. In the meantime the 5.0 branch is just 0.10.

Another issue with changing all the syntax in 5.0 is that we will continue to maintain 4.x and merge into the 5.0 branch with every release for a year or longer after 5.0 release, so if the code is too drastically different without any user benefit, it makes simply maintaining express way harder for no reason.

[jimmywarting]

If the only benefit was syntax, we can use Babel to transpile to old versions. What do you think?

The way i see it is: It's only meant to run on the backend, It doesn't have to have to work for multiple clients like it's on the web. If the minimum requirement is version x, just update you node version it's not that hard... therefore using babel and transpile it to worse code is a unnecessary step and make it more complicated and just adds up more time waiting for it to compile durning developing and auto testing.

I really wish node has some kind of auto update so that we don't have to make it backwards compatible cuz some ppl never update 😠

I would not mind seeing a error message that it requires version 7. I would gladly update my node version.

[wesleytodd]

I am in support of upping the min to 4.0, but I am completely against using babel or any transpilers in the core packages, and am also against changing the syntax in core package for the "sake of change". That being said, there are some perf and readability improvements we can make if we start using some of the new stuff where appropriate.

It's only meant to run on the backend

Not true, I am running, or plan to run, most of this code in the browser.

I would not mind seeing a error message that it requires version 7. I would gladly update my node version.

This is NOT the feeling of the rest of the ecosystem. Upgrading node versions in production is something we try to avoid doing more than every few months. And an important package like Express cannot force this.

[dougwilson]

P.S. I like everyone's use of the emoji reactions. I feel like it actually adds to the conversation when reading it without too much text noise.

[matheuslc]

@dougwilson I agree with you. The focus is users, but, we are users too. For contributors, it's fun to play in a updated code base (actually, Express code base, in my opinion, it's really awesome).

I agree with @jimmywarting, in this case, if anyone have to use some older Node version, they can use an older version of Express. If they want the newest things, they should to update their Node version. With this, we are pushing Node & Express forward.

[wesleytodd]

it's fun to play

I agree, but please do not "play" in the code that powers the website that pays my bills. I recommend you take a look at the work being done in pillarjs and jshttp, and just build your own "play" project.

That being said, I am in support of the min version change to node 4.x, so don't construe my comments as against the main point of this issue.

[yawetse]

Out of curiosity, why Node 4.x and not 6.x? Would it be possible to keep the releases of Express in sync with LTS versions of Node?

[wesleytodd]

@yawetse Express supports 6. In this case we are talking the minimum supported version. And 4.x is still widely used. So the main changes that would be based on this discussion would actually start using features not present in <4.x. So chancing this discussion to <6.x is pretty much out of the question because of the broad usage.

** If you look above, the main core team is not even fully in support of dropping 0.12, cant imagine going even further :)

[yawetse]

@wesleytodd got it, makes sense. I apologize for not reading the full thread previously.

I know Express supports 6, but I think if you're starting a project today, then you might as well start on Node LTS, and by that logic, if you're building a new Express app today, then it should have on its min requirements Node LTS.

If you have an existing Express app that's working for you, nothing would force you to migrate to Express 5. But given what you said about the state of the current conversation, this seems extremely unlikely.

[matheuslc]

@wesleytodd You are being literal. Currently, I'm using this project in production, so, I want the best for it and I want to contribute too. I don't use any word of your comment.

[wesleytodd]

@yawetse I think the concern is that if we do not continue supporting the older versions, it takes even longer for users to all get upgraded to 5, and the team then has to continue to support the old version of Express. So the goal is to get the largest adoption as quickly as possible, users of old Node included. FWIW, I totally agree about starting a new project, but that is not what Express core is.

@matheuslc Sorry if I miss-understood your intent with the above comment. I just meant there is a difference between learning new features of the language, and supporting an important, widely used and deployed project. And this is not the place to try out new features IMO.

[matheuslc]

@wesleytodd Sometime we have to do it. Why not now? I'm not saying that we have to use the latest Node version, but we have to start it anytime. Node was in the version 7, maybe version 4 it's a good start point. The longer we take to do this, the worse it will be in the future.

[dougwilson]

@matheuslc I don't disagree that we are not some kind of user persona as well, but an issue that we would have to contend with is the fact that we are going to support Express 4.x for at least an entire year after Express 5.0, so if the code bases diverge too greatly, performing the merges from 4.x into 5.x will become more and more painful. The argument to use an older version of Express is valid, and is certainly why we are going to maintain it for years to come, but if we make maintaining Express 4.x itself a burden that we cannot merge & maintain, then the argument to "just use an older Express" is not a valid one to make, since it's not being maintained.

My assumption has been that once Express 5.0 came out, the 4.x/5.x dual support would work exactly how the dual support for 3.x/4.x worked: all new features continues to land in the older version as long as they are possible there and they are simply merged up into the new version. This is especially important for bugs, since bugs are the primary thing we would be doing in 4.x.

I hope that makes sense at least where my mind is at. I think that the discussion for rewriting the internals of Express in ES6 is certainly _related_ to the discussion of bumping the min version of Express, but not exactly the same discussion, because even if Express bumps the minimum to 4 or 6, that still doesn't mean we would rewrite the internals in ES6, as that is a separate discussion, which needs to take into account things like what exactly is the support story of how Express 4 continues to work when the code between the two are so different they are unmergable.

[matheuslc]

Awesome guys. Let's do it!

[kibertoad]

@dougwilson I presume that accumulating opinions for 3 years was quite enough :). Was there any decision in the end? Also if any help is needed to convert some of the old code to ES6, I absolutely volunteer :).

[dougwilson]

Hi! Thanks for volunteering! You can see my thoughts on a ES6 rewrite in my previous post above. If you can help make some proposals on how to overcome the issues brought up above, that would be the first please to start.

[kibertoad]

@dougwilson Would it be an option to use Babel for Express 4 to transpile distributed code into something 0.10 would understand? Unrelated question: is there any work towards Express 5.0 that could be picked up by someone new to Express codebase?

[dougwilson]

I'm not familiar with Babel, so can't say either way, but it would be if you know it is, haha. All the Express 5.0 code is on the 5.0 branch.

[kibertoad]

@dougwilson Idea behind Babel is transpiling JS code that is written in newer JS syntax (e. g. ES2017 or ES2016) into equivalent JS code in older syntax. Its main purpose is compatibility with older browsers (cough IE), but it should work fine with Node.js as well. If you think this is a viable way forward, I can work on PR for an npm script that would put transpiled code into /build folder. Npm publishing configuration will also have to be adjusted to only publish the transpiled code, but I would need your assistance with that as I obviously have no means to test Express publishing pipeline :). Yeah, I understand that Express 5.0 code is in its branch, I'm mostly wondering if there is some work that is currently lying around unassigned and would speed up 5.0 release if taken :).

[dougwilson]

The issues are labeled with 5.x label. Keep in mind that many people require files in Express module directly, so that needs to work after whatever you're talking about. For example require('express/lib/utils') needs to continue to work on 4.x releases, it cannot suddenly become require('express/build/lib/utils') or it will break existing 4.x apps.

[kibertoad]

@dougwilson Yes, I understand that. Published module needs to retain exact same structure as it does now. Since NPM doesn't natively support that, I'd have to get creative, but it appears to be doable: https://stackoverflow.com/questions/38935176/how-to-npm-publish-specific-folder-but-as-package-root

[jimmywarting]

I don't want it to be transpiling with Babel. I rather want it the way it already is then. Transpiling means it get harder to debug and it and the over all size, compile time and complexity gets larger.

I think we should follow nods LTS.

The issue started with dropping support for node < 4 and now you want to add Babel for compatibility with older version...! A bit of track if I may say so.

Code that runs with Babel are actually slower and I don't want that for a server that needs to handle many connection.
Newer features brings micro optimization and mimic what it dose with Babel is not as good

[mansona]

Not to be controversial or anything but Node LTS for v4 is due to end on 2018-04-30 as described on the Node release schedule

If we don't think that v5 of Express will be released before then I would be up for dropping support for even node v4.

Now it's unlikely that we would get much support if we did that, but I think ☝️ this kind of thinking should at least draw the line under all pre-v4 versions of node. They are out of date and anyone who wants to use Express with them should be comfortable locking to express: ^4 in their package.json.

[dantman]

Publishing a transpiled ES5-only build of expressjs also kind of feels pointless. We're not browser bundling express, so we always have the option of including both the ES2015+ source compatible with the current node LTS and the transpiled version compatible with older node.js and just using feature tests to require the correct version for the environment /* ???.js */ module.exports = <supports 8.x features> ? require('src/???') : require('build/???');.

[mansona]

I think it is a really bad idea having any "official" transplied version of express, because if it is official then it needs to be supported.

Don't forget that Node 0.12 was End of Life over a year ago now, and as the LTS documentation suggests it is no longer getting any security patches. If we release anything that is specifically to support versions that have reached EOL then we are in a way complicit in encouraging people to still use versions that they really shouldn't be using in production.

I understand that there are legacy concerns for enterprises etc but in those cases, our default position should be "Lock your package.json to v4"

[kibertoad]

@jimmywarting @mansona @dantman Please read https://github.com/expressjs/express/issues/2755#issuecomment-279887674. While I myself would approach this in a more straightforward deprecation way, it is ultimately maintainer's call to make, and he has made it. According to the latest statistics, 0.10 makes around 20% of all Node.js installations, and decision was made not to abandon them. Hence our question is not "Drop or not drop 0.10 for 4.x", our question is "How do we get ES6 in 4.x at all".
Speaking of performance - do you have any benchmarks to reinforce that claim? Older Node.js versions are kinda terrible at optimizing ES6 code execution and it used to perform consistently worse than ES5, so I wouldn't be surprised if certain code would actually work faster after transcompilation.
Debug concern is definitely valid, though. I'm thinking that it might be possible to "pseudo-transpile" original unmodified code into something like /dist-es6 folder with modified package.json that would be published as a separate package so that whoever wants it could opt-in into ES6 4.x version, but that's something I would have to discuss with @dougwilson.

[kibertoad]

@dantman Dynamic imports with feature tests is definitely an interesting idea, though, I'll definitely consider it in implementation, as that would simplify publishing process a lot.

[LinusU]

I think that dropping support for Node.js 0.x is absolutely the right thing to do for Express 5. But that doesn't mean that we have to rewrite it in ES6 just because it's fun...

We need to continue support for Express 4 for a long time, and Express 4 can never drop support for Node 0.x (that would breaking and then it would be Express 5).

In order to be able to easily backport patches from Express 5 to Express 4 we want to keep the codebase as similar as possible. While one way to do that is to rewrite both to use ES6, and then babel the Express 4 code before sending it to npm, I don't really see the benefits with that...

Apart from how express looks on the inside, would there be any benefit to the consumers of express should we rewrite it in ES6?

[igor-savin-ht]

@LinusU ES6 is not meant for consumers of express, it is entirely for the benefit of express developers. So the benefit of consumers would be increased productivity of developers and decreased amount of bugs (due to stricter variable scope/mutability checking, less boilerplate etc)

[LinusU]

The thing is, I don't it will be less work for us since the work for backporting patches to Express 4 will be much more than otherwise.

Still, I like ES6 as much as the next guy, and I think that we should get there eventually. But Express is a really big project and has a ton of users.

In this case, I think it's better to be a bit conservative and focus more on the consumers of the library then the developers.

just my 2¢

[igor-savin-ht]

@LinusU Hence the plan to use Babel in Express 4. Then no additional work for backporting patches would be necessary at all.

[LinusU]

Yeah, that could potentially work. Although I personally don't think that the increased complexity would be worth it...

[wesleytodd]

Sorry I am a bit late to the discussion here, but here are my thoughts:

Dropping support for node versions in 5.0.

We should officially drop support for everything before the current LTS version at release time. Older versions will probably still work, but that doesn't matter, we will not officially support it. It looks like that will probably mean everything before node 6 at the current pace.

Transpiling with Babel

I think this is very bad path, and we should avoid it for all express modules and dependencies. It introduces bloat, difficult debugging and increased chance of buggy code. This opinion comes from having deploy and supported servers transpiled with babel, not just speculation.

Goals for introducing ES* into Express

We should take it slow, and only implement thing that are better for users. This would include things like:

• Performance improvements (if a new feature is faster)
• Security improvements (if we have to change something because of a security issue and there is a good es next way to do it)
• Better user facing API (for example, promise/async/await support)

General thoughts on these kind of changes

I think it is a real shame that so many people are being taught that "using ES6 is better" without taking any time to think about WHY. I am with @LinusU when I say that I like ES6 as much as the next person. There are a TON of features in the language now which are great, and we should be focusing on being relevant. But more importantly we should focus on the service we provide to our users, which is being a reliable and stable server. So lets stick to doing that, not rewriting code as an "academic adventure".

Also, people keep saying things like "es6 is more maintainable" & "write es6 because it is better for the developers". But in most cases the things people are doing to "improve developer experience" is adding complicated tooling (like suggesting Babel). Which does the opposite of improving developer experience.

[igor-savin-ht]

@wesleytodd So what you are saying is "No ES6 before Express 6", right?

[wesleytodd]

No, 5.0 will probably drop during the LTS for node6. And node6 has a ton of es2015 features. So IMO, the outcome of this issues discussion should be: start using node6 compatible es2015 features in your PR's to express projects. But I would like to hear @dougwilson's opinion on that statement.

[wesleytodd]

For reference: http://node.green/

[wesleytodd]

Also, I should have specified:

With my above stance, we will have to do a small amount of back porting work. I think this is an acceptable consequence for staying relevant. But where work is too far divergent, we should reign in usage of new features to keep that amount of work small and manageable.

[LinusU]

@wesleytodd Agree 100% with all you are saying 👍 thanks for taking time to write it all down.

I just have one small thing that we should think about:

Older versions will probably still work, but that doesn't matter

I'm quite sure that this actually happened before with express (maybe with 0.6, need to look it up, anyhow...). We didn't officially support it, but it still worked. At some point, we introduced a commit that broke 0.6 compatibility, and released it in a patch release.

Now, we didn't officially support 0.6, but people were still using it, and thus they opened issues complaining. I don't remember how we solved it, I think we fixed the compatibility.

In the end, we don't want to break the end user, and unfortunately I don't think that people read, but rather just install. So if it works on Node.js 4 when we release it, I think that people will both use it, and complain when we break it.

I think it would be smart to add some guard that would hard fail it straight from the beginning, just to prevent people trying to use it without reading which runtimes we support...

[wesleytodd]

I think it would be smart to add some guard that would hard fail it straight from the beginning, just to prevent people trying to use it without reading which runtimes we support...

I like this idea. And fully agree with were you are coming from on it. Couldn't we also use the package.json engines field?

[igor-savin-ht]

@wesleytodd This directly contradicts what @dougwilson was previously saying. I'm not arguing with you, I would prefer more aggressive migration stance as well, but I make an assumption that this is something that maintainer is supposed to make decision on.

[wesleytodd]

I can see how @dougwilson and my opinions differ, but I think "directly contradict" is a bit strong :)

And that is why I said "I would like to hear @dougwilson's opinion on that statement". I am in favor of a slightly more aggressive migration path than we are currently using. But there is a difference between "more aggressive" and "re-write it all in ESnext".

[igor-savin-ht]

@wesleytodd True :)

[dougwilson]

Hi all, sorry I am traveling today so my access is off and on. I read through all the comments and will definitely write up my thoughts when I'm at a computer soon :) The thoughts in https://github.com/expressjs/express/issues/2755#issuecomment-365011388 from @wesleytodd most closely align to my thoughts and is nicely worded. I will provide further clarity on my thoughts later today when I don't have to type them on a phone, but was hoping this would at least help a little in the meantime.

[kibertoad]

@wesleytodd Btw, there was an idea voiced earlier about dynamic Express.js imports based on feature checks - then those who are using more modern Node.js and do not rely on direct imports would get the proper non-transpiled version. Do you see any problems with this plan?

[wesleytodd]

Do you see any problems with this plan?

Yes I do. It is more code to maintain, and unless we were exposing a different interface to the user, they wouldn't even get any benefit. So there is no upside to doing such.

[boneskull]

It's my hope the Express team will drop support for unmaintained versions of Node.js as soon as is feasible. Mocha has already dropped support for v0.10 and v0.12, and will drop support for v4 ASAP.

FWIW, "dropping support" does not imply "rewriting"; it can be as straightforward as removing the version from the matrix in .travis.yml.

[dougwilson]

We already confirmed we are dropping support for them in 5. What still needs to be clarified?

[boneskull]

@dougwilson Sorry, it sounded like it was somewhere short of "official"--I saw v0.10 and v0.12 were dropped already, but not v4. But if that's the plan, then great! 👍

[dougwilson]

When 5.0 is released it will support down to the LTS version at that time.

[sam-github]

xref: https://github.com/expressjs/generator/pull/244#issuecomment-562680659

its not clear what

When 5.0 is released it will support down to the LTS version at that time.

4052c15c7f10b79fb7c54f3837ffe118f7a99811 was first alpha, in 2014... but 5 is still in alpha, in 2019, and at this moment the only supported Node.js version are 8.x (until January 1st), 10.x, 12.x, and 13.x, see https://github.com/nodejs/Release#release-schedule

Is it possible for 5.x to drop support in the middle of the multi-year alpha process?

Should 5.x be left in alpha, perpetually, and 6.x be the new alpha, with only support for 10.x and later?

These are questions larger than whether the default express-generator output installs a version of pug with security vulnerabilities, so this is likely a better place to discuss.

[dougwilson]

Is it possible for 5.x to drop support in the middle of the multi-year alpha process?

Sure, why not? Is there some reason why we couldn't do this?

Should 5.x be left in alpha, perpetually, and 6.x be the new alpha, with only support for 10.x and later?

No.

[sam-github]

Is there some reason why we couldn't do this?

The outcry from users of 5.x-alpha, who did not pay attention to https://semver.org/#spec-item-9

Shall I PR a drop of EOL node from appveyor.yml, .travis.yml, and package.json to master? And is that the only things needing changing?

[dougwilson]

Would it be different than the outstanding PR https://github.com/expressjs/express/pull/3948 ?

[vansergen]

@dougwilson I think it is a good idea to drop old Node versions. It would speed up the development process and allow to implement new features. Do you plan to keep support of Node <10 in the next release (5.0)?