Is using #include "component.c" considered bad practice or is there any misra standard rule violation? (potentially rule 3-3-1)
So far, I understand that it is a commonly categorized as bad practice but can be used in certain scenarios, would it be any particular concern for safety-critical applications?
Misra rule 3-3-1 states that Objects or functions with external linkage shall be declared in a header file
When you write a program like that, it is called a unity build. A good example of such a program is the compiler for the Odin programming language. So it can be done, but like anything else, there are tradeoffs.
It puts more source into a single translation unit. This can help optimization, similar to how link-time-optimization works since the compiler can actually see the source from functions in other C files.
Less clutter in project files (less headers), and therefor, less repetition.
A greatly simplified build; It may be as easy as building only one file even if many files are in the project.
Harder to understand for co-workers who use more common practices.
You can no longer define a static variable with a very generic name in a C file, because that C file could be part of a bigger translation unit. You will wind up with more verbose variable names.
It will generally slow down the build. Build systems (like make), can speed up compilation by only re-compiling what is dependent on all changes. If you are combining things into a single translation unit, the whole thing will need to build for every change. In a big project, this will lead to more memory consumption during the build.
You cannot parallelize the build.
I don't actually know, but it doesn't violate the rule you posted:
Misra rule 3-3-1 states that Objects or functions with external linkage shall be declared in a header file
By including a C file, you know longer have external linkage because they are in the same translation unit.