search

AmpersandJS / ampersand-filtered-subcollection

Filterable, sortable, proxy of a collection that behaves like a collection.
MIT License
11 stars 7 forks source link

update travis config #26

Closed wraithgar closed 8 years ago

wraithgar commented 8 years ago

I think it's time to update our travis configs. Starting on this repo for nor particular reason, will move on to others if I get no pushback here.

kamilogorek commented 8 years ago

Any particular reason why we should use npm@v2.0.0 (other then v3 being slooooooooow.....)? Also are we sure we want to test it on node@v4.0 only?

wraithgar commented 8 years ago

To be honest those are the defaults I've seen used in other current build configs that are generated for your (by things like semantic release for example).

I don't know that we've ever defined our node version contract with ampersand, so 4 being lts seemed like a good start. We could easily decide to run multiple versions.

The npm thing is a little more tricky, as I don't really know how we'd test both 2 and 3 at the same time.

The only thing I am sure of is that testing on v0.10 and npm 1 isn't really giving us a good indication that this works in newer environments that people are definitely using right now.

None of this addresses testing of modules that only currently run in the browser environment. That still needs to be re-addressed, as I believe those tests currently aren't working, and they arguably need to be the way we test all ampersand modules (I think making sure they run in different browsers is just as if not more important than node version).

I'm going to go ahead and ping @AmpersandJS/core-team on this one as I'm sure this module isn't that highly watched, but this is as good a place as any to have this conversation.

wraithgar commented 8 years ago

Trying to get saucelabs testing working here

wraithgar commented 8 years ago

Ultimately if we get tests working in zuul then it doesn't matter what node or npm version we're on. I think sticking w/ 4 for now is a good option since it uses npm@2. Npm@3 flattens dependencies which means that it's possible for a require to work in 3 but not 2.

wraithgar commented 8 years ago

It looks like the tests are hanging on iOS in saucelabs. They pass fine for me locally in iOS Simulator. We may need to consider paring down or support contract in .zuul.yml to get tests working.

wraithgar commented 8 years ago

Ok going with latest version only on ios/android.

There is no way currently in zuul to change your reporter (i.e. to something like tap-spec) so the output is too egregious right now to do anything other than latest on mobile, imo.

wraithgar commented 8 years ago

Ok I think I've threshed out all the duplicated/assumptions-based items in the config

cdaringe commented 8 years ago

node 0.12, node 4.x

tracking w/ LTS is a safe move. im in support of 4

if we get tests working in zuul then it doesn't matter what node or npm version we're on

yep!

nice work :)

kamilogorek commented 8 years ago

Im fine with latest LTS as well :)

wraithgar commented 8 years ago

Ok I'll merge this and start making PRs in other repos as I have the time.

kamilogorek commented 8 years ago

:shipit:

wraithgar commented 8 years ago

@AmpersandJS/core-team IE9 support has been mostly consistent except for in things like ampersand-dom-bindings

So far the fix, if it could be made to work, is obtuse. Should we drop IE9/10 support, given that Microsoft has done the same?

cdaringe commented 8 years ago

if something as critical as dom-bindings hasn't worked, then have we really ever supported it?

herkyl commented 8 years ago

I agree with @cdaringe. If dom-bindings are not working there's not much of IE9 support to talk of

latentflip commented 8 years ago

As a counter-point: a) how broken is IE9/10 support currently on dom-bindings? b) is it actually broken or is it just that the tests were broken?

From the other thread, it sounded like only getAttribute('style') was breaking, and even then that was only being used in tests? If that's it I'd say that yes we have supported it, just with a bug or two?

wraithgar commented 8 years ago

At this point it appears that switchAttribute either doesn't work, or if it does is extremely difficult to test for (display is coming back empty or null when it should be block or none). Once I get ampersand-sync brought up to speed I can revisit it, again.

There were also whitespace inconsistencies with the className attribute which we would also have to readdress if we supported IE9/10.

wraithgar commented 8 years ago

Currently the PRs for ampersand-view and ampersand-dom-bindings are the only ones pending, and that is because I could not get the tests to work in IE9 or IE10. In order to even see what's needed to get them working I'm gonna need to install those in a vm or something, which will take time as I find it.

cdaringe commented 8 years ago

@wraithgar, watching all your great work here got me thinkin. maybe using @nlf's git-validate we can manage all of this stuff a bit easier. that is to say, release a module called something like ampersand-validate which, on npm install, copies over the .jshintrc, .zuul, etc etc. then, when these things get updated, we just bump the version of ampersand-validate. this prevents us from having to do manual file updates in ~10 bazillion repos. maybe give it a cutesie or fun name. ampersand-legos, ampersand-kitty-litter, ampersand-shield, ampersand-afterburner, ampersand-straightjacket. i dont know. think that would be cool?

wraithgar commented 8 years ago

Yes that's a great idea that I would give all the +1's to but in no way have the time to do myself, if that makes sense.

phantomjs@2.1 just landed which means we can go back and remove the function.prototype.bind shim from our tests that need it, and switch that one defineProperty back to a value instead of a getter.

ETA: the publish methods we have in most but not all of the repos would also be a good thing to have this proposed module add.

wraithgar commented 8 years ago

Turns out there's a giant monkey wrench here. PRs from forks aren't going to test. https://github.com/defunctzombie/zuul/issues/86

I've tried setting the variables in the travis config for one of the repos and it still doesn't work. Not sure how to approach this.

Our options are:

cdaringe commented 8 years ago

@wraithgar, i've made it pretty far with my bulk updater suggestion above. https://github.com/cdaringe/ampersand-family-meeting . tests are currently... lacking.

right now it clones or pulls everything ampersand-* land (even unofficial), makes some changes, adds them, commits them. it really needs to fork first, then push to forked-feature branch. as a test, i have them all install standard into dev dependencies, then would possibly add a precommit hook to run it precommit.

so the question is, what do we want to easily keep standardized across the whole ecosystem?

still more work to be done, by hey, let's get serious about unity!