Best way to add "for current user" routes that don't take a User ID? about gitbeaker HOT 19 CLOSED

Just pushed another release with some more fixes. Going to let it settle for a few days to see if i missed anything serious and then ill officially release it

from gitbeaker.

Yup!

from gitbeaker.

Hey! I've recently tackled this problem and will have a beta release ready by the end of this weekend. for this case it will be somehting like

UserKeys.all({userId})

Where the userId is optional, if its passed it with be for that user, else it will be for the currently authenticated user.

Does this work for you?

from gitbeaker.

Honestly that makes even more sense than GitLab's own URI design. As long as it also has add and remove, that will actually be almost everything we need. While I have your attention, do you think you could sneak "get forks" into that release?

from gitbeaker.

Check the most recent beta release, tell me if it works for you!

from gitbeaker.

I was skimming the diff and I noticed the push to Node 9. Did you sneak any Node 9 features in? We have a big cruise ship of an app and only fairly recently managed to get it on Node 8, so that would be a no-go for us. If it's safe to do so, perhaps on our own fork of this we could downgrade that assertion back to 8, for the sake of our CI/linter.

from gitbeaker.

Yea a few, I can put it back to what it was before which compiled down to 8.9.0 ? Just trying to keep the the library up to date :(

from gitbeaker.

Besides the immediate inconvenience to us personally, I'm most concerned about us using something versioned against 9 because odd-numbered Node releases do not go into LTS when development finishes on them. For our part, I suspect we're probably going to stay on 8 until we can make the jump to 10.

Unfortunately you seem to have the only good node module for gitlab API v4 at the moment... 😅 We'd love to rely on this excellent package, but in our particular case we need to distinguish between "up to date" and "bleeding edge". If you don't expect to use anything exclusive to Node 9, it may be better for adoption to stick with 8. If that's unpalatable then we can fork this and build it against 8 ourselves - but if we can, we'd like to avoid having to worry about pulling in ongoing updates from this base repo.

from gitbeaker.

thats fair! Ill keep it compiling down to 8 lts!

from gitbeaker.

By the way, I really love the defaulting = {} behavior for options, so you might consider doing that for e.g. UserKeys, so that people don't need to provide an empty object when omitting user ID.

from gitbeaker.

Oops! Must of missed it thanks!

from gitbeaker.

It's not clear what the intended way to use 3.0.0 is, aside from the addition of the new keyword. (We definitely want to stick with the "Basic Import" since we are going to use many namespaces.) I really like v2's way of not needing to use new, and getting an object where namespaces can be accessed as properties. I think the Examples section in rc2's README may be out of date; or if not, it should define what the api variable refers to.

from gitbeaker.

I agree with not using the new keyword, but in v2 it was inconsistent and without it would require alot of self initialization which was what i was trying to avoid. It is annoying though im aware :P.

Ill update the examples to show the import so the variable makes more sense. Its just a reference to the above basic import examples.

Minus the new key word, the availabilty of the namespaces as properties are still present!

import Gitlab from 'node-gitlab-api';

const api = new Gitlab({ my credentials here });

api.Projects.all()
api.Groups.all()
api.SystemHooks.show(2) 

//etc

Sorry for the confusion!! If i can make it any clearer please dont hesitate to say anything :D

Edit: Added more docs, tell me if that helps !!

from gitbeaker.

That's definitely what I was expecting. The issue I was having is that when I create a new Gitlab, I end up with something that doesn't have those properties on it. Instead it's something with the Namespace prototype.

from gitbeaker.

from gitbeaker.

I had assumed you intentionally changed something 😆

from gitbeaker.

from gitbeaker.

Yup, i had conflicting variable names. Fixing now!!

from gitbeaker.

Should be good to go now :) v3.0.0-rc.3

from gitbeaker.