express
express copied to clipboard
expressjs
build: drop node <8
When 5.0 is released it will support down to the LTS version at that time.
Originally posted by @dougwilson in https://github.com/expressjs/express/issues/2755#issuecomment-382499774
I am not sure about this, if the code still passes is there a reason to drop all of the targets? Obviously we will convert to using some new features like arrow functions at some point, but those are supported back until at least like node 4. Is there a reason to stop running the tests in the "likely to still work" scenarios? Maybe we could only remove them when we introduce changes which intentionally break them?
I do not have super strong feelings here, it just seems to me like stopping testing them unless we actually break them is really abrupt.
@q4w56 We don't currently use async functions in express core.
So I guess my point is that testing express core against these older versions doesn't hurt until we introduce an actually breaking change. We will not "support" them, but I guess I think it might be better for us to keep testing it until the first PR which actually breaks compatibility.
We don't currently use async functions in express core.
Maybe because no pr can use async functions before this pr lands?
We don't currently use async functions in express core.
Maybe because no pr can use async functions before this pr lands?
Word!
Your statement is the opposite of how this project operates. Until PRs are put forward that utilize new features that cannot be supported in older versions is how said older versions get dropped, as then there would be a purpose to drop said support.
express may not have code that fails on EOL Node.js versions, but express-generator depends on a beta version of pug that has a sec vuln, and updating to secure version fails on 0.10 and 0.12: https://github.com/expressjs/generator/pull/244
Is that sufficient to drop CI for EOL Node.js versions?
Is that sufficient to drop CI for EOL Node.js versions?
Not necessarily unless there is no possible solution otherwise. The standard Node.js issue template usually asks folks what alternative solutions they have considered prior to their request, so maybe it may help to understand the same thing here: are there alternative solutions / which have you considered already? Or maybe are there no possible alternative solutions and why?
Sure, there is an alternate solution: explain to users that express generator creates apps that have audit warnings by default, and they should ensure they update the dependencies before using its output as the base for a production app. When they ask "why does it do that?", maybe "tracking audit warnings is an important part of the lifecycle of a production app, this give you the opportunity to start doing that right away".
I'm not sure if that comment was made in good faith and instead out of frustration. Maybe you need to cool off? I'm not sure I should provide a response at this time based on the tone there. Please correct me if I'm mistaken.
Hey, sorry to resurrect the off-topic conversation, but the express generator right now is an issue IMO. It is just totally old, full of cruft, and promoting bad practice. I have started the work on a new and complete re-write which I have not yet pushed to that repo. That said, I just opened a proposal to our governance which might help things like this not happen in the future. @sam-github, I would love your input and if you are interested in working with me to improve the generator that would be awesome! Hit me up on that repo or on twitter to discuss.
note: marking this as off-topic after I post!
Dropping support for old versions of NodeJS will probably help getting new contributors, as no one wants to support older version of NodeJS with legacy ecma script features. Seeing that old versions of NodeJS are still supported can be a big no go.
