In the first place, any class you do write should be inheritable/extendable. C# seems to seal all its system classes and so causes me no end of trouble. Inheritence is tricky, particularly when the superclass programmer doesn't know what the subclass programmer will need and the subclasser can't modify the superclass. (And in some cases cann't even look at the superclass's code.) But inheritance can give your end users a lot of power for very little effort on their part.
But otherwise, I'd go with composition. I frequently start with a base class, extend it in all directions, then realize the base class should be an interface. If it's all in my code, this is no problem, but people using your library are going to be stuck with your choice. In Java I've ended up with two classes that look identical as far as my needs are concerned. If I could make each of them implement my own simple interface (by adding "extends myInterface"--they've both already got the methods) I'd be all set, but I have to treat them as distinct, unrelated classes.
The best idea might be to provide good interfaces and default implementations so the end users can do whatever they want. I guess my point is that your library's users should be the ones to make the composition vs. inheritance decision; your job is to give them the option.