grab supported node versions from `travis.yml`

[jonathanong]

would be pretty cool

[rlidwka]

You mean, use github api to fetch those every time website builds?

[jonathanong]

yep

[dougwilson]

another possibility is to grab it from the npm rest api like npm info vary engines.node.

[jonathanong]

i think the versions of node actually tested make more sense. people could write whatever they want in .engines.node

[rlidwka]

Is there any place in package.json where leading maintainer name is stored?

(we could grab _npmUser of last published package version from npm, but that sounds weird)

[dougwilson]

we could just use the author field and just alter that to be the lead person, i guess?

[rlidwka]

comment out original author's name (so it will be there, but won't be active) and replace it with current one maybe

[dougwilson]

well, json can't have comments :( copyright would still persist, which is what is really important. it's too bad you cannot list multiple people as authors, lol

[rlidwka]

I was about to suggest something like I'm using for forks, but... oh... right... json... you see why I don't like that

Something like this maybe:

"__author": "original author",
"_author": "old maintainer",
"author": "new maintainer",

I know that copyright persists, but nobody is usually looking at the copyrights unless they have to.

[dougwilson]

well, if we're going to make up new fields, why not just add a "leadMaintainer" property :)?

[jonathanong]

we can just remove author and put everyone as contributors. then put the lead maintainer at the top. i don't think the original author matters.

[jonathanong]

i don't really feel like adding new fields haha

[dougwilson]

@jonathanong i think your suggestion fits the best. do we know what npm does if we don't even put an author field, btw?

[jonathanong]

no idea

[jonathanong]

i don't even know if it does anything with contributors. it's just documented in the package.json specs

[dougwilson]

i'll check it out

[dougwilson]

so normalize-package-data module thinks author is optional, so i say we go with @jonathanong for the maintainer stuff: don't include an author field and the first person in contributors is the "lead contributor" /cc @rlidwka

[rlidwka]

... and then you forget to change that when leading maintainer actually changes...

looking at how npm shows Last Published By instead of an author, maybe my original thought about "_npmUser" is not as bad as it seems

[dougwilson]

i guess :) but i'm sure there'll be times the non-lead-maintainer will publish, especially when people are on like vacation or something, haha

[rlidwka]

... then the lead maintainer would be automatically changed. There is no point to display unavailable people there anyway. :)

[rlidwka]

added such script in 9b04d4e9acd6b7c4939083764993019e4b15cb60 , here's script output: https://github.com/jshttp/jshttp.github.io/commit/f2252c9356f8c5173100ab03e9bfee6a9ac2085a

if everything looks good, I'll change build.js and templates to make use of that data

[jonathanong]

nice! only thing i can think of is that we should be able to overwrite the scraped node version in projects.json, specifically mime-db :D

[rlidwka]

yeah, just leave one human-maintained database, and another one... hm... call that script-maintained :P

so first one will overwrite second one

[rlidwka]

implemented in https://github.com/jshttp/jshttp.github.io/commit/9b04d4e9acd6b7c4939083764993019e4b15cb60 and https://github.com/jshttp/jshttp.github.io/commit/b964caf5e8c87ba0612a2ad72aa577095f0c938c

[dougwilson]

we could also get mime-db to actually run on 0.6 in travis if we removed all the newer dependencies from devDependencies, haha

[rlidwka]

do they still support 0.6? lol

I remember people talking about its deprecation last year

[dougwilson]

yea, it's still supported over there. you do have to add a command to get npm to work, but it's still usable, haha. i had it run, even, but the devDependencies (because of the harmony script stuff) makes it fail.