Get rid of warning when printing --help

[Feder1co5oave]

This fix.es #992

https://nodejs.org/docs/latest-v8.x/api/child_process.html#child_process_options_stdio

[joshbruce]

@Feder1co5oave: Will this break backward compatibility with older versions of Node? What versions of Node do we even support does anyone know? (Tagging @UziTech and @matt- as well)

I never thought to ask whether people used Marked while running Node servers.

[Feder1co5oave]

I haven't thought about this, however that `stdio` option was added in node 0.7.10, so we should be ok? I think?

[UziTech]

according to the current travis.yml we are testing for 0.6 but I think we should aim for Node >= 4

P.S. This doesn't really fix #992

The problem there is that marked --help calls man which doesn't exist on Windows.

We should call man if on Mac or Linux or just display something on windows.

[Feder1co5oave]

You're right, this doesn't fix 992. Still it lets us migrate to a non-deprecated option, I would merge this and pass on to think how to solve the help problem. I say we get rid of the man page. It's not being mantained. We could use the README.md file or generate a new help message.

ps. Let's consider commander

[Feder1co5oave]

I was also thinking about updating the dependecies. We should update travis.yml and maybe package.json with a e.g. {"engines": {"node": ">0.10"}} section?

[joshbruce]

Good stuff here. Couple of things for my edification and whatnot.

Right now we don't use a CI tool inside GitHub - and I'm not sure @chjj is considering coming with us on that at the moment. So, is the travis.yml so others can incorporate Marked into their CI pipeline?

@Feder1co5oave: Can you create a ticket for the commander proposal? Given what I've seen so far from previous conversation when @chjj was more active, there is a desire for minimal dependencies, which I tend to agree with - but am not hardcore about it.

Re Node version: It does seem odd that we are 0.10 - not one of the majors. Having said that, are we supporting that far back because we can - Marked doesn't need anything greater? Are we not able to take advantage of something because of that (maybe a Node standard library, or something - not a Node guy)?

[Feder1co5oave]

Before updating the engine version, I would try setting up travis for marked in order to test it on various node versions and see how it works out. We should also set up travis.yml such that tests are automatically run at every commit/release. @joshbruce are you by any chance able to sign up to http://travis-ci.org and enable the marked repo even though you're not the owner?

[UziTech]

We also should update the travis.yml #967 I don't see any reason to continue supporting node 0.x

You can set up travis to run on a fork but it would be nice if @chjj could hand over the repo so @joshbruce could enable travis on all PRs

[joshbruce]

@UziTech and @Feder1co5oave: Sorry, thought I responded to this already.

No, I can't. Would love to though.

I don't have access to anything behind the "Settings" tab on GitHub. If I owned the repo itself, of course, that would be different.

I'm finding that to be one of the drawbacks to open source projects that aren't financially backed - you really gotta love it, or be making money with it somewhere else. Of course, the alternative is a whole other set of ethical issues.

[joshbruce]

#956

[styfle]

I think this should be added to the 1.0.0 milestone or whatever is considered the next breaking change milestone. We will likely want to drop support for Node < v4.0.0 and this (stdio) was added in v0.7.10

[joshbruce]

@styfle: Sounds legit to me.

Can I ask why you didn't mark it?

Is there still confusion you think on when that will be? The whole #1077 conversation makes that totally reasonable as well. Was going to write something about it in the co-pilot issue, think that would help?

[styfle]

Is there still confusion you think on when that will be

Yes. I still advocate for a 1.0.0 release as soon as possible. To quote semver.org:

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

Ideally, 1.0.0 means dropping support for legacy node.js environments.

[styfle]

Can I ask why you didn't mark it?

@joshbruce What does this mean?

[styfle]

@Feder1co5oave Can you push to trigger a build?

[Feder1co5oave]

Will do as soon as I can

[Feder1co5oave]

@styfle done

[styfle]

@Feder1co5oave Excellent, thanks! 👍

CI is green (minus security checks), I think we should merge this as part of 0.4.0

@UziTech @joshbruce Any objections?

[Feder1co5oave]

I think only node >= 0.10 is being supported right now so this shouldn't break anything?