You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Reach out to Travis to get option that includes #205
This is already doable by adding matrix lines in .travis.yml for each LTS signifier that nvm supports, as well as node. I'm not sure how it would work to have something in the yml that created more than one item.
Yes, it is possible to do this and we should evangelize that, however I think this issue is to change the default, i.e. the behavior when you have no versions defined. At the moment it will only run in the latest stable - I think we should advocate that it should run in the latest stable + latest LTS and that is without adding any lines other than language: node_js in the .travis.yml.
I also think that lts/* was intended to support multiple LTS versions, but maybe they never got around to implementing that.
So, to summarize, what I'd really love to see travis do is support the following:
node latest stable Node.js release (same as they currently)
lts/active all active LTS Node.js releases (there is no such option right now)
default: current (or active or smth like that) equivalent of having both node and lts/active in the version list (currently: default is node).
Maintainers can then chose to stick to the default (ideally) or override to only test in one or more specific lts/latest/whatever they feel like.
I’m the maintainer of nvm who invented “lts/*” - in no way was it ever intended to support multiple versions, it’s a single star and behaves the same way a single star does on the command line, selecting the first matched version only.
That would still indicate a single version; nvm (travis’ sole means of deciding node version) does not have any concept of selecting multiple versions, only listing them.
I can certainly ask Travis to change the default matrix to have multiple jobs, but i anticipate pushback about the complexity for users of getting, say, 3 jobs by default, adding 1, and ending up with 1 - if that comes up, how should i respond?
Ideally, library maintainers, esp. for popular libs, should be testing at least in all active LTS plus stable, but if that's not feasible (there's an obvious cost associated with 3x the job runs), then the current default of stable is a good one, I would say.
Regardless of that, adding a way to define "all active LTS" in a single line of .travis.yml, which does not need to be maintained, would be an awesome feature.
And even without that feature, possibly Travis could update their docs to highlight the current behavior (that people might not be testing in LTS by default) and include a recommendation with an example of a manual configuration. I'm happy to try and work on a proposal for the docs (not sure if they have them in the open so people can PR).
part would really be helpful. @ljharb if a single entry mapping to multiple entries does not fit the model any other ideas? I wonder about something like LTS-latest, LTS-1, LTS-2 or some other way to try and catch all of the active LTS versions which would not have to be updated for each new release.
@ljharb any chance there's an update on this? I'd be keen to hear any and all opinions from Travis, before I start drafting #204... Can I be of any assistance on the nvm side of things (a stretch, given I'm no bash guru, but still)?
@dominykas the more i think about it, the more i don't think it's really compatible with travis without being built into nvm. (the renovate link 404s for me)
iow, anyone who uses my shared travis configs will get new LTS versions automatically, since i add new node versions to that repo pretty rapidly (and eventually could automate it with github actions).
as an example, node v13.2 just was released, so now every project using the "minors" presets will automatically test on it also (as opposed to instead of 13.1), on their next travis run.
Should we have this under @pkgjs? I know @ljharb is not some rando on the internet, but if we were to make an official recommendation - should that be in an official repo?
It does a bit more than just include the relevant versions (e.g. npm run tests-only support)? Do we want to be that opinionated? I think I'd favor something that has just the basics.
It would probably make sense to provide includes named based on the keyword convention we have for package support?
As for the tests-only thing, that's kind of necessary if we want to separate linting, from auditing, from tests - since npm test is supposed to always run 100% of your tests, I've chosen "pretest", "posttest", and "tests-only" as the convention. There always has to be some convention since there's no way to do npm test --ignore-scripts, unfortunately.
If I understand it correctly, Travis can import just the nodejs bit - it doesn't need to have the script, env, etc? Similarly, while I personally also prefer to have nvm install-latest-npm in my CI, I would not say that this is the 100% default for everyone?
That's a fair point; I can separate out the matrices, and the "latest npm", to separate imports, to allow people to pick and choose those and define their own script/pretest/posttest settings.
Separately tho, I'm not sure what use case anyone has in CI for not testing with the latest npm :-)
Separately tho, I'm not sure what use case anyone has in CI for not testing with the latest npm :-)
I can come up with several edge cases, alright... Not sure if they're relevant for people publishing to public npm, though. One example is doing stuff with docker - the base images have a fixed npm which is distributed with the node release. Then there's occasional edge cases for more complex situations with peer deps and/or shrinkwraps, which are about to get breaking changes and ever so often have regressions. Then there's the logic of using the same npm your users are likely to use (i.e. default one bundled with node - although I'd love to see some stats on this!)
Anyways, like I said - I'm with you on this one ;) just not sure if we want to make it the default.
Note to self: we should update best practices to include this, if they don't already do that.
Activity
ljharb commentedon May 13, 2019
This is already doable by adding matrix lines in
.travis.ymlfor each LTS signifier that nvm supports, as well asnode. I'm not sure how it would work to have something in the yml that created more than one item.dominykas commentedon May 14, 2019
Yes, it is possible to do this and we should evangelize that, however I think this issue is to change the default, i.e. the behavior when you have no versions defined. At the moment it will only run in the latest stable - I think we should advocate that it should run in the latest stable + latest LTS and that is without adding any lines other than
language: node_jsin the.travis.yml.I also think thatlts/*was intended to support multiple LTS versions, but maybe they never got around to implementing that.So, to summarize, what I'd really love to see travis do is support the following:
nodelatest stable Node.js release (same as they currently)lts/activeall active LTS Node.js releases (there is no such option right now)current(oractiveor smth like that) equivalent of having bothnodeandlts/activein the version list (currently: default isnode).Maintainers can then chose to stick to the default (ideally) or override to only test in one or more specific lts/latest/whatever they feel like.
Docs: https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#specifying-nodejs-versions
Edit: update to reflect @ljharb's commend on the intent of
lts/*.ljharb commentedon May 14, 2019
I’m the maintainer of nvm who invented “lts/*” - in no way was it ever intended to support multiple versions, it’s a single star and behaves the same way a single star does on the command line, selecting the first matched version only.
dominykas commentedon May 14, 2019
Cool, thanks, good to know! Did not realize this comes from
nvmand assumed it's a glob.Updated to suggest
lts/activeinstead.ljharb commentedon May 14, 2019
That would still indicate a single version; nvm (travis’ sole means of deciding node version) does not have any concept of selecting multiple versions, only listing them.
I can certainly ask Travis to change the default matrix to have multiple jobs, but i anticipate pushback about the complexity for users of getting, say, 3 jobs by default, adding 1, and ending up with 1 - if that comes up, how should i respond?
dominykas commentedon May 14, 2019
Ideally, library maintainers, esp. for popular libs, should be testing at least in all active LTS plus stable, but if that's not feasible (there's an obvious cost associated with 3x the job runs), then the current default of
stableis a good one, I would say.Regardless of that, adding a way to define "all active LTS" in a single line of
.travis.yml, which does not need to be maintained, would be an awesome feature.And even without that feature, possibly Travis could update their docs to highlight the current behavior (that people might not be testing in LTS by default) and include a recommendation with an example of a manual configuration. I'm happy to try and work on a proposal for the docs (not sure if they have them in the open so people can PR).
mhdawson commentedon May 17, 2019
I think the
part would really be helpful. @ljharb if a single entry mapping to multiple entries does not fit the model any other ideas? I wonder about something like LTS-latest, LTS-1, LTS-2 or some other way to try and catch all of the active LTS versions which would not have to be updated for each new release.
ljharb commentedon May 18, 2019
hmm, probably the easiest way would be for me to add a similar feature to nvm; then travis can get it by default.
dominykas commentedon Jun 3, 2019
@ljharb any chance there's an update on this? I'd be keen to hear any and all opinions from Travis, before I start drafting #204... Can I be of any assistance on the nvm side of things (a stretch, given I'm no bash guru, but still)?
dominykas commentedon Jun 3, 2019
By the way, renovate does have some syntax on this: https://renovatebot.com/node/
ljharb commentedon Jun 3, 2019
@dominykas the more i think about it, the more i don't think it's really compatible with travis without being built into nvm. (the renovate link 404s for me)
dominykas commentedon Jun 3, 2019
Looks like a bug in renovate docs routing or smth, here's a link that works: https://renovatebot.com/docs/node/
26 remaining items
ljharb commentedon Nov 14, 2019
This can now be achieved trivially by using my shared configs: https://twitter.com/ljharb/status/1194728750698487808
iow, anyone who uses my shared travis configs will get new LTS versions automatically, since i add new node versions to that repo pretty rapidly (and eventually could automate it with github actions).
dominykas commentedon Nov 15, 2019
👍 This is great!
What about deprecating old versions?Oh, I see - it's dependent on the include. Nice.ljharb commentedon Nov 15, 2019
Happy to add any additional composable "presets" to that shared repo as folks need it.
mhdawson commentedon Nov 21, 2019
Very nice !
ljharb commentedon Nov 22, 2019
as an example, node v13.2 just was released, so now every project using the "minors" presets will automatically test on it also (as opposed to instead of 13.1), on their next travis run.
dominykas commentedon Nov 27, 2019
@pkgjs? I know @ljharb is not some rando on the internet, but if we were to make an official recommendation - should that be in an official repo?npm run tests-onlysupport)? Do we want to be that opinionated? I think I'd favor something that has just the basics.mhdawson commentedon Nov 27, 2019
I'd be +1 for having it under @pkgjs
ljharb commentedon Nov 27, 2019
I'd be happy to fork it into an official org, and then keep both remotes updated at the same time.
ljharb commentedon Nov 27, 2019
As for the
tests-onlything, that's kind of necessary if we want to separate linting, from auditing, from tests - sincenpm testis supposed to always run 100% of your tests, I've chosen "pretest", "posttest", and "tests-only" as the convention. There always has to be some convention since there's no way to donpm test --ignore-scripts, unfortunately.dominykas commentedon Nov 27, 2019
If I understand it correctly, Travis can import just the
nodejsbit - it doesn't need to have thescript,env, etc? Similarly, while I personally also prefer to havenvm install-latest-npmin my CI, I would not say that this is the 100% default for everyone?ljharb commentedon Nov 27, 2019
That's a fair point; I can separate out the matrices, and the "latest npm", to separate imports, to allow people to pick and choose those and define their own script/pretest/posttest settings.
Separately tho, I'm not sure what use case anyone has in CI for not testing with the latest npm :-)
dominykas commentedon Nov 27, 2019
I can come up with several edge cases, alright... Not sure if they're relevant for people publishing to public npm, though. One example is doing stuff with docker - the base images have a fixed npm which is distributed with the node release. Then there's occasional edge cases for more complex situations with peer deps and/or shrinkwraps, which are about to get breaking changes and ever so often have regressions. Then there's the logic of using the same npm your users are likely to use (i.e. default one bundled with node - although I'd love to see some stats on this!)
Anyways, like I said - I'm with you on this one ;) just not sure if we want to make it the default.
Note to self: we should update best practices to include this, if they don't already do that.
ljharb commentedon Nov 28, 2019
I’ll comment here once I’ve separated out the unopinionated parts.
dominykas commentedon Aug 28, 2020
We now have https://github.com/nodejs/ci-config-travis - if there's no objections, I'll close this issue in a week or so?