-
-
Notifications
You must be signed in to change notification settings - Fork 149
node-gitlab 2.0 refactor #79
Comments
Also a big question is about staying with CoffeeScript versus going to plain Javascript I personally like enforced scoping CoffeeScript introduce, but we saw multiple times developers complaining about the language. As the project is growing, I prefer to use the most accessible language so we can get more developers to contribute. |
How about return a backbone model? |
@moul re: CoffeeScript, heh, this project is the reason I learned CoffeeScript and now prefer it over JS :D |
@mdsb100 I don't think using Backbone is a fit for what we are doing:
We're building a library interface to the API, not a web application. GitLab itself may want to use Backbone in their interface, but it doesn't apply to our use case. |
Titanium use backbone model. Please check http://docs.appcelerator.com/titanium/latest/#!/guide/Alloy_Collection_and_Model_Objects |
Again I think this is because that is used for building applications, with user interaction, rather than an API wrapper. This is similar to having us put a CLI in our library, you should use our library to create a CLI (which you have done). You could wrap the objects we return in Backbone models. |
We can try to write or find an already existing Blueprint of the Gitlab API (https://apiblueprint.org), then we can generate a tree definition of the API calls, parameters, return values, errors @dave-irvine yes, I also prefer CoffeeScript but I still can do vanilla JavaScript, and we can replace the coffee compiler in the Makefile by some JavaScript linters to keep a constant code quality |
OK, I got it. The node-gitlab just be a backbone.sync. |
Maybe the Backbone object can be one of many interfaces. But I think we need to keep the original object as minimalist as possible |
I think #65 is not suitable. If we try to do this, then we must create some models to store or control data. |
@moul I think I like the idea of APIBlueprint, but doesnt GitLab themselves need to maintain that? |
@dave-irvine yes I think they need to, if they don't already have it, we can create a pull request on their repository with the base file |
Firstly, we should use node callback conventions. It's deadly important. |
@RobinQu As long as we expect callbacks to be |
@dave-irvine That would be fine. |
I definitely like the idea of supporting Promises. I've worked with both Bluebird and request-promise before. PromisifyAll from Bluebird has worked really well for us. I installed node-gitlab, then I modified a few of the functions to have https://gist.github.com/JogoShugh/ea69d69c51e78fa42eba#file-asyncawait-js I saw someone had submitted a pull-request with Promisify stuff in it, but I guess it's outdated now? Here is another example of where we use it: https://github.com/openAgile/eventstore-client/blob/promisify-all/lib/projection.js#L72 So long as the callbacks follow the node callback conventions, it's really that simple! |
👍 for Promises. Can understand why this project uses coffeescript since this started in 2012, but moving away from coffeescript to es6(with babel) would definitely attract more developers to contribute to this project. It would allow a module level import like lodash. Options object as the argument definitely feels like a natural choice over here. |
+1 for node convention callbacks. Also not sure who's idea it was to return true if something already exists but an informative error would be a lot nicer. |
I would agree that at a minimal following the Node convention would be a tremendous improvement in the consumer experience. Second, I've also used Bluebird to promisify the GitLab interface, similar to @JogoShugh. I haven't quite made it to transpiling with Babel to get async/await, but I'm excited about the prospect. The example provided by @JogoShugh is extraordinarily concise, and easy to read (no nested callbacks, and no As for coffeescript versus JavaScript, personally I'd prefer native JavaScript using ES6 features available in Node LTS versions (or at most, babel). Then again, I'm not the one that's going to have to write, or support, this library, so my preference carries little weight. I will say that adding a feature to Lastly, I agree with @garrettjoecox. I just spent quite a while trying to figure out why I was getting |
Hi, reading the comments I remembered, that there is a discussion at gitlab about swagger (as far, as I know) something similar to blueprint. https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2397 Just for the record :) |
One year has passed, is the refactor is still WIP? Looking forward to easier combination with Promise. |
Promise+1 |
We're considering the following for a 2.0 refactor that will break backwards compatibility:
function (err, result)
.options
parameter, rather than mixing up what parameters they take. See Fix #70 #72 for more details.We'd like to get community thoughts on this refactor. We're considering maintaining a 1.x branch for a while to address any outstanding critical issues.
The text was updated successfully, but these errors were encountered: