old flags for previous node versions should result in no-op, not error, for current version (?)

[ORESoftware]

This regards Node versions 6.7 and 4.5, but could possibly involve more versions.

In v4.5, we could allow for deconstructive assignment with the --harmony_destructuring flag.

However, in v6.7 if we use that flag, it says:

node: bad option: --harmony_destructuring

and a quick check => node --v8-options

shows us that the new relevant flag in version 6.x is called:

--harmony_destructuring_assignment

So what that means is that I need some conditionals in my library such that if a user is using a certain version of Node I use the first flag, and if the user is using another version of Node, I use the second flag.

Is there a way to mitigate this problem?

I suppose that one solution could be that using --harmony_destructuring with Node version 6 should result in a no-op (just a warning or something) since it was a flag that existed in old Node versions.

[mscdex]

See #8395 and #8445. This is the kind of thing I was afraid of -- more requests for no-op flags. I am still -1 on doing this.

[ORESoftware]

I can see the downsides, just want to say this is something that happened to me is not externally motivated by any existing issues :)

[ORESoftware]

To illustrate exactly what I am talking about, the main problem case for me is, we have bin files in Node projects, that usually start with something like:

#!/usr/bin/env node --harmony

now if I want to support destructuring in older node versions, I would do:

#!/usr/bin/env node --harmony --harmony_destructuring

but this throws on the latest version, so I would have do some weird bash conditional logic to switch commands based of the node version. If someone knows how to that conditional logic, then I would be willing to forget about this :)

and to take this one step further, imagine if the latest version is Node 17, and someone throws in the --harmony flag, is it a no-op or do we throw an error? Seems like going forward best to just log a warning or something and make it a no-op.

[cjihrig]

Still -1 from me as well.

[ORESoftware]

@cjihrig the underlying problem for me was described immediately above, is there a solution? Node is making it hard for me to support multiple Node versions for a library that is supposed to support multiple Node versions :)

[cjihrig]

You shouldn't be using the harmony flags for production grade code. They enable features that typically aren't production ready. If you just have to use the latest and greatest language features for some reason, you can transpile the code.

[ORESoftware]

Good point

[Fishrock123]

Imo this is the risk you take hard-coding flags anywhere. Major versions may change them in dependencies, that's just how it is really.

[ORESoftware]

Well, backwards compatibility is a nice-to-have :) Just because JS changes fast doesn't mean Node.js has to not be BC. Ok maybe it does :)

[Fishrock123]

The existing policy has already been to not support backwards compat for dependency flags across major versions. I don't think that has or will change.

[hashseed]

Backwards compatibility for experimental feature flags... If you really want to go that way, why don't you just write a wrapper script that omits flags that are not listed with --help?

[targos]

-1 from me as well. I don't want to have to maintain floating patches for experimental flags support.

Can we close this? It seems no collaborator has expressed a favorable opinion.

[bnoordhuis]

Yes, let's close. I'm -1 as well.