How should we manage front-end dependencies?

In my opinion, we should use composer, because forcing another dependency manager onto everyone seems like overkill. It makes a number of things more awkward, e.g. that "composer create-project" won't work any more as an installer. Users of SilverStripe would need to install NodeJS on their dev environments to use a PHP CMS.

This would work for jQuery and TinyMCE, but not Jasmine, the jQuery plugins we have.

So, it would be an incomplete solution. If we want to push all 3rd party dependencies into separate packages then we'd need to work with the package maintainers to get them into packagist, or we'd need to upload them to packagist ourselves. Or we could just leave some of the dependencies in framework/thirdparty.

Alternatively, we could use bower on a module-by-module basis, and check the bower dependencies into git. This would still have the effect of cluttering our git repos with code that we don't maintain. I'm not convinced that this is better than using composer for front-end packages where we can.

As for the problems of using composer for front-end packages: we current block all direct HTTP access to the vendor/ folder. We'd need to open that up, and lock items down more selectively.

Are we overlooking npm, here? I don't do a lot of frontend work, but my perception is that npm has become the standard for managing frontend libraries. It does introduce yet another system, but I think any frontend developer who has been working in the last two years would expect to use npm over something like composer or even bower.

One of the benefits of using node modules is that we could use proper dependency injection in our scripts, e.g. require('jquery'), and clean up the global namespace.

npm vs. bower is a debate worth having, especially if you look at moving JS/CSS aggregation into that layer.

However, I'm a little concerned about requiring that SilverStripe users pick up these tools... Maybe if the .tar.gz downloads are functional (e.g. they come with composer.phar so that people can add/remove modules when starting with the .tar.gz download)

I'm also not sure about how composer packages would specify additional npm dependencies, for when a module has a front-end dependency.

I don't really think there is any perfect solution yet. There is no package manager that combines all dependencies we have (php, js, css).

I remember there was a time that some core people used piston & git for non php dependencies in the framework/cms.

I agree that getting other people to learn yet another tool just to get all the code they need will present an issue.
Perhaps the alternative is to manage non php dependencies with a manager, but commit the full files including the config files into the repo, so it is only used to updated (just like it was done with piston).
(Or perhaps, if we want to split that up, a composer project that contains the js+css dependencies and bower/npm/... config files)

We often work with junior or client developers who have a relatively narrow focus on, say, CSS or HTML. It has been a challenge to get them using git, gitflow, and composer; never mind adding, say, a ruby dependency so that they can run capistrano. Then there are the ones using Windows.

So, the fewer non-PHP dependencies we can manage, the better.

@fredcondo the decisions on how to make the framework the best it can be shouldn't be based on making the life of junior devs easier.

Look at Vagrant or a similar tool to give all your team an "out of the box" working development environment.

We are completely agnostic to host OS because all development is done on a VM that has all the dependencies ready set up on provision

@danielhensby I appreciate that point of view, but as a practical matter, client & partner devs (never mind junior devs) that we have to work with have little chance of getting vagrant up and running on Windows, for example.

I have no problem wrangling VMs. The issue is that we can't impose infrastructure on our clients even if the benefits are manifest.

So, if we can avoid adding dependencies, that would be nice. No, that should not hold back the framework. But we should be mindful that each additional dependency will marginally reduce the audience for the framework.

I think keep inlining the dependencies would be the safer option. Adding further complexity to the contribution workflow could push developers away.

Don't be so quick to discount junior devs.

Junior devs are what make WordPress #1.

And unfortunately WP sends them down the wrong path to learning PHP. ...or at least the 1990's path. ;)

Sr. Devs also need to be able to teach it to their teams. The simpler it is, the lest costly it is for companies to support it.

Something not mentioned yet:
The SilverStripe community could contribute to Composer to better enable front-end support.

Regarding NPM -- We recently had a need to install NPM on our servers and our Ops team pushed back like none other. They inspected the NPM package itself and said it was a huge mess and would present security vulnerabilities due to its difficulty in upgrading.

I wasn't thinking it would be something that's required. I believe the bower docs suggest you do keep the installed packages under vcs. The idea for me is that if all or most js libraries are installed via a package manager it's easier to upgrade one library (jquery) and know what libraries are compatible from there (in an ideal world). I'm afraid I don't have enough experience with any of them to suggest a solid way forward though.