Where should shaders and lights be in a component-based entity system?

A component-based entity system works best when an entity represents something in the logical game world and a component some single aspect of that entity, generally things that you'd want to compose.

An entity may have a component that describes visual properties or behavior of an object. A component that represents a sprite or model, for example. It is perhaps appropriate to have a component that represents the fact that some entity emits light in a certain fashion. But those should just act as proxies, game-logic packages of information that are ultimately fed into the renderer in a more optimal form.

Do not make the mistake of going overboard with your "entity system" and putting everything in there. Not everything should be a component; it is a horrible way to architect anything at scale, and trying to homogenize everything in that fashion can result in extremely confusingly-coupled and poorly-performing code.

To that end, the renderer should not know about or process component types. It should understand the representation of sprites or models, shaders or lights in the viewable space and the rendering of those sprites/models/lights in an efficient manner. It should not have any dependencies on the entity/component system at all (I mean this literally: you should be able to compile the rendering code without including the component code).

Rather, have the components (which are naturally a game logic domain) store pointers or references to the renderer (which is naturally a lower-level part of the technology stack) if needed to avoid duplication of data or inefficiency state transfer every frame. But do not directly couple the entity system and the renderer.