by Sam Hemelryk.
First up this is a very worthwhile discussion.
Really after reading through this thread I don't think the implementation is in question here yet. I've looked over it and I think there are a couple of things we still need to address there but all in all Andrew you've done an excellent job there.
I think what really needs to be decided is whether or not we want to dive down this rabbit hole and commit our selves to the first build process required by Moodle for development.
There are several advantages that having a build process brings that would not be otherwise achievable.
Really the highlights are:
# Native minification (remember we have three sources of JavaScipt: yui core modules, yui gallery modules, and moodle yui modules).
# Lint
# Automated tests
We'd benefit from the minification immediately, having lint easily runnable means we could, should we choose to, start to improve our JS code standard, and really tests would require much more work. Of course with tests it is much easier to write tests for new code than existing code so perhaps we could benefit early on from 2.5 development.
If we choose to adopt this build process there are other advantages. We'd be keeping up with YUI who is in the process of adopting this for their gallery I believe, and we'd be putting ourselves in a position to realise the benefits of having better code through use of tools that support better code development.
Its worth mentioning that we could probably integrate each of these separately and that while we may be able to avoid the need for a build process we would still require external tools, the implementation would be more complex and it would not be nearly so well self contained/organised. The build process ties all of there worthwhile features together.
The negatives... well lets face it the big one is you would have to build JS before using it.
Against that argument is that node.js is easy to install and well supported plus we have --watch.
Regarding integration I don't see any issues there, we'd perhaps have to decide whether we build everything as part of the release process, probably a good idea and is what YUI does themselves.
Adoption by developers should be fun, but nothing good documentation and support won't ease.
Certainly it would be master only, it would be a huge change and wouldn't be backportable.
I don't imagine changes will cherry-pick across nicely for those backporting bug fixes, unless git has some switch to allow fuzzy logic or user specificed path matching.. I don't know about any such thing but I havn't delved into that area of git either.
Personally, I would like to see a JS build process adopted and Shifter seems like the best choice given its YUI's own method of building.
The implementation is a whole other story, presently I'm happy just throw my vote into the "Yes I want it" box.
Of course this change would affect a lot of people, perhaps it is worth having a tracker issue for this so that we can go and vote?
Many thanks
Sam
Really after reading through this thread I don't think the implementation is in question here yet. I've looked over it and I think there are a couple of things we still need to address there but all in all Andrew you've done an excellent job there.
I think what really needs to be decided is whether or not we want to dive down this rabbit hole and commit our selves to the first build process required by Moodle for development.
There are several advantages that having a build process brings that would not be otherwise achievable.
Really the highlights are:
# Native minification (remember we have three sources of JavaScipt: yui core modules, yui gallery modules, and moodle yui modules).
# Lint
# Automated tests
We'd benefit from the minification immediately, having lint easily runnable means we could, should we choose to, start to improve our JS code standard, and really tests would require much more work. Of course with tests it is much easier to write tests for new code than existing code so perhaps we could benefit early on from 2.5 development.
If we choose to adopt this build process there are other advantages. We'd be keeping up with YUI who is in the process of adopting this for their gallery I believe, and we'd be putting ourselves in a position to realise the benefits of having better code through use of tools that support better code development.
Its worth mentioning that we could probably integrate each of these separately and that while we may be able to avoid the need for a build process we would still require external tools, the implementation would be more complex and it would not be nearly so well self contained/organised. The build process ties all of there worthwhile features together.
The negatives... well lets face it the big one is you would have to build JS before using it.
Against that argument is that node.js is easy to install and well supported plus we have --watch.
Regarding integration I don't see any issues there, we'd perhaps have to decide whether we build everything as part of the release process, probably a good idea and is what YUI does themselves.
Adoption by developers should be fun, but nothing good documentation and support won't ease.
Certainly it would be master only, it would be a huge change and wouldn't be backportable.
I don't imagine changes will cherry-pick across nicely for those backporting bug fixes, unless git has some switch to allow fuzzy logic or user specificed path matching.. I don't know about any such thing but I havn't delved into that area of git either.
Personally, I would like to see a JS build process adopted and Shifter seems like the best choice given its YUI's own method of building.
The implementation is a whole other story, presently I'm happy just throw my vote into the "Yes I want it" box.
Of course this change would affect a lot of people, perhaps it is worth having a tracker issue for this so that we can go and vote?
Many thanks
Sam