I was also wondering about starting to use a frontend package manager. Bower is the only one I'm very familiar with and I've found it slightly more confusing. I'm not sure how you'd use it on a project level instead of just within a single module. I've already seen a few module authors starting to use it though. For example:

• https://github.com/silverstripe-ux/sass-twitter-bootstrap
• https://github.com/ryanwachtl/silverstripe-foundation-theme
• https://github.com/clintLandrum/silverstripe-productreviews

I don't think the conversation should diverge into frontend package managers or dropping IE8 support.

It looks like entwine does support new versions of jQuery (https://github.com/hafriedlander/jquery.entwine/) so that should be fine.

Agreed, @zauberfisch and @markguinn please feel free to start a frontend related discussion thread and dialog about it there :)

@danielhensby when you say "does support new versions" which version in your opinion would be the likely target for us to upgrade to for v3.2?

@nicolaas I'm not a huge fan of arbitrarily upgrading jQuery every other release because it kind of puts SilverStripe in an awkward lockstep with jQuery. Most of the time it would probably be inconsequential, but when jQuery has some radical API change it might make for a protracted release cycle for SilverStripe to get everything working.

I can see what you're saying about having some kind of predictability, but by the same token, I think most module developers are aware that major releases will require them to revisit their code and make updates.

@camfindlay1 @danielhensby while I agree that dropping a browser or a package manager is a whole different subject and should not be discussed here,
you can't on the other hand ignore the fact that those issues are related.
and I think the breaking changes that have happened recently are a good chance to also do a major jquery updated (as @unclecheese pointed out, module developers will need to go ahead and update their modules anyway).

@zauberfisch, @lozcalver has put forward the proposal to implement a jquery change. I suggest once that proposal has run it's course, we run a followup proposal looking at how we might actually implement that and using which tools (composer? bower? something else??).

@camfindlay1 I am not sure you understand what I am trying to say.
I actually think that the package manager should be in another thread. I only started it because someone was speaking of composer.

What I am really saying in the context of this thread is, how about upgrade to jquery 2 instead of jquery 1.11?
(Dropping IE8 is just a result of using jquery 2)

Thanks for the comments all!

@samminnee1 I think switching to dependency management for third party software is definitely worth discussing. Perhaps even worthy of an entirely separate discussion (e.g. why stop at just jQuery?).

@nicolaas @unclecheese I’m inclined to agree with the suggestion of upgrading for "minor" versions (i.e. 3.2, 3.3, 3.4 etc). I think for usual semantic versioning this isn’t a good idea, but seeing as we’re introducing API changes with these version bumps I see no reason why we can’t update third party libraries at the same time.

@zauberfisch I believe we do still support IE8, so unfortunately switching to jQuery 2.x may have to wait :(

@markguinn @danielhensby I’d be very anxious about looking at anything other than composer for dependency management. The reaction to composer (even though it’s optional) has been pretty mixed.

@camfindlay1 I believe (I’ve not tested) that 1.11.x should be fine - the readme states that 1.10.x is supported and I don’t believe there were any major changes for 1.11.x. Would be good to get feedback from Hamish on this too I think.

Just to get my thinking in order. Composer is used by the end developer to manager what they want to see in their project. Would this frontend manager be controlling the dependancies for the CMS module only (and therefore is something us as core commiters care most about), or are we putting forward a tool for end users to use?

@camfindlay1 I'm not sure I'm an expert in determining which version we should go for. But my preference would be that if we're going to make breaking changes, to go as far forward as possible. IE: The latest jQuery at time of release of 3.2

I wouldn't consider using jQuery2 as it's nice to have 1.x available and if that'd be the only thing breaking IE8, then it's zero effort to include it and have IE8 support

I’d also be in favour of keeping IE8 support for now - it’s not like IE8 is holding the CMS back, plus the data saved by using jQuery 2 is minuscule relative to the size of all the JS assets we load.

I understand the concerns about upgrade headaches: upgrading jQuery will break at least one of my modules that I know of. However, the way I see it is that if we don’t upgrade for "minor" versions, how out-of-date will it be by the time 4.0 comes along?

Is there anything we can put in place to help smooth the transition between jquery versions?

@simon15 and @stiglindqvist can you perhaps provide us with some more details of your concerns here? Perhaps there is something we as a group are missing or haven't considered in our decisions?

My main concern's actually with the upgrading process. There's already one change in 3.2 that's going to make upgrading difficult (no, it's not the ORM one. That is completely backwards compatible outside of database adapters) and adding something else in – especially something that only people that have more of an investment in the PHP-side than the HTML/JS-side have voice opinions on – is going to decrease the uptake of a new version.

@ingoschommer perhaps it would be good to go into some of the difficulties you perceive here. I appreciate your position as a core developer and most likely have a much deep understanding of the issues here. Also don't forget Loomio has a "block" vote, essentially a veto which in situations like this could be used (and I think we should use them sparingly when coming from an informed position that something really should not go forward).

@simon15 can you be explicit as to what that particular breaking change is that you mention above please. Have you got any ideas on how we might smooth the process of upgrading if we were to upgrade jquery? (As a thought experiment rather than an absolute solution).

@camfindlay1 They've already been brought up in this discussion multiple times.

In the interest of being constructive and trying to work through the issues here can anyone else comment as to an approach that might allow us to get the jquery upgrade we seem to want while being proactive toward making upgrading tolerable.

Are there any tools/scripts we could build and provide developers to help overcome the pain point should we go ahead with it. If so who would put their hand up to build them and where would these tools reside?

What I am attempting to do is get a good handle on the ramifications that exist alongside the making of our decisions and ensure decisions are made with a decent amount of insight and understanding. Some of you in the community know more about these things than others, therefore we rely on you to help inform and educate the others in the community.

Perhaps the jQuery migrate plugin is what we need to include in the CMS? https://github.com/jquery/jquery-migrate/

Interesting, so this could perhaps be a good bridge to let us both update to newer jquery in core while still supporting older jquery modules for a period of time?