DI in class library best practices

Pretty simple question - let's say I have API project and referenced library. The API project owns application composition root and construct all the dependecis together. In library project we incapsulate some parsing logic, the key thing here that we have some predefined parser, but also would like to give

an option for the API to inject some custom parser in the future.

So four example,

public TemplateParsersFactory(
ITemplatesContentProvider templatesContentProvider,
IParameterParserFactory parameterParserFactory)
{
public void RegisterParserFor(string parserKey, Type parserType) {}

public ITemplateParser GetParserFor(string templatePath){}
}

So here we have some sort of TemplateParsersFactory, which actually duplicates functionality of IoC container in API project. We can register parser and resolve it, when we need it. In my opinion I would ask API project to implement some interface like ITemplateParsersFactory and provide more or less the same implemention of TemplateParsersFactory, but using IoC container. Would it be a good idea? We own the code of all projects.

Another thing that parsers for now are added to the TemplateParsersFactory on library side, when you constract factory, something like this

var parserFactory = new TemplateParsersFactory(
templatesContentProvider, parameterParserFactory);
parserFactory.RegisterParserFor(".tf", typeof(TriggerParser));

I think it would be much better idea to allow IoC container to resolve?

And just in general, if library provides some extension points with some default implementation all of this magic should wired up in one place in application composition root?