Enhancement proposal: simpler Gruntfile.js
dagnelies opened this issue · 4 comments
I just wanted to state my preference over a much simpler Gruntfile.js
Currently, it's split into many files, using some import mechanism, etc. and feels unintuitive.
https://github.com/ractivejs/plugin-template/blob/master/root/Gruntfile.js
I think an ordinary Gruntfile like this would be better:
https://github.com/ractivejs/Ractive-decorators-sortable/blob/master/Gruntfile.js
I know the first one was explicitly made to avoid that "configuration files can grow unwieldy" when it grows. However, I'd like to point out that most Ractive plugins are fairly simple and require a straightforward build. ...in this case, IMHO, an ordinary Gruntfile would be way simpler and intuitive than its current counterpart.
This is one of my priorities as well - in fact, I'd go much further and ditch grunt altogether. This has already happened with several of the plugins, e.g. https://github.com/ractivejs/ractive-events-keys. It uses gobble rather than grunt to build the library (same as Ractive itself), and the source is an ES6 module that cuts out all the boilerplate (it gets converted to UMD during the build).
The one thing it doesn't yet do is provide an easy way of creating a demo page. What I'd really like to do is create a plugins.ractivejs.org site where plugins ('official' and third party) can be indexed and previewed. Haven't yet had the time to properly sketch out what that looks like, but it's definitely on the radar.
Because there's no gobble equivalent of grunt-init, I'm not sure what the future of plugin-template looks like. Maybe it should be delegated to a dedicated ractive-cli tool? (This was first considered over a year ago, we haven't got round to it yet...)
that sounds like a lot of changes.
To be honest, I found releasing a plugin slightly complicated.
As a web developer, I often feel overwhelmed by the amount of techs popping up and things you have to learn: gruntjs, bower, now gobble. What the heck, tomorrow will be another one for sure.
To be honest, I don't even think you should be responsible to "how" people build, uglify, test their scripts or whatever.
In the end, what you need is simply the plugin script file and a demo page. Who cares if they use grunt, or gobble, or nothing, or whatever. Right?
I'll even go to the extend that you don't need all of that. Instead, what I think would be great is to let users submit a script url and a fiddle as demo, and voila! Done.
Wouldn't that be easier for anyone? You could just display the list of links, description and their fiddle demo. You could drop this whole plugin template stuff, submitting a plugin would be dead easy and testing/playing with it would be just one click away in the fiddle.
What do you think?
I hear you - I flip-flop daily between wanting to pare everything back to the bare bones, and wanting to automate all the tedious stuff away.
To be honest, I don't even think you should be responsible to "how" people build, uglify, test their scripts or whatever.
There's nothing to stop someone doing it their own way, of course. Ultimately, the point of a project template is that it has certain opinions (about how you structure, test, document and release your code), in order to make things smoother and more consistent (e.g. as a plugin consumer, I might be using AMD, CommonJS or <script> tags, so it makes sense for UMD to be the standard across plugins, but as a plugin author I might not know or care about UMD. Having a project template solves that problem), though...
To be honest, I found releasing a plugin slightly complicated.
...I'll concede that it doesn't always work out that way.
I'll even go to the extend that you don't need all of that. Instead, what I think would be great is to let users submit a script url and a fiddle as demo, and voila! Done.
I would love for that to be the case! I think it'd be great if you could just write some stuff into a gist and voila. If there's a practical way to do that, I'm all for it. But it means that that plugin probably doesn't exist on npm, it probably doesn't use semantic versioning, and probably doesn't have documentation (or tests, not that I want to throw stones in that particular glass house...) - all of which make it very difficult for other people to use, which is the whole point of releasing it as open source in the first place. A lot of that 'admin' stuff is tedious for experts and intimidating for newcomers, which is where a good project template comes in.
I'm not saying we're there yet (not even close), just making the case for a more fully-featured template.
yeah, I got it, I see your point.
Before I continue, I would like to say that this template is actually quite nice in several ways and provides lots of "best practices". It's great for plugins that are a bit more complex and require what you mentionned (versionning, docs, ...)
On the other hand, I believe that the majority of plugins would be rather simple or very simple, yet very handy as well.
...for example: a date-picker widget. It's probably a dozen of lines or so. It's a small potatoe, yet a very useful one.
Writing the widget is one thing, making a plugin out of it is another. For the dozen of line of this date picker, you'll have to learn grunt, wonder about bower, make it available through npm, version it, setup a github webpage... Well, let me tell what that person will do: it won't make a plugin out of it. It's oversized for such a simple plugin.
I'd try to make making a plugin as easy as possible in order to maximize the chances that people make some. I think an ordinary gruntfile would be the first step in that direction. And please, no offense, but I'd rather keep gobble at bay. It may be great but I'm tired of learning new tools every day, I guess I'm not the only one. At least, some of us are familiar with grunt.
Cheers