I have used Tridion to publish CSS and JavaScript many times in the past.
Please keep in mind that every implementation is different. What I've done may not work with what you've done.
Code Component + Page template
The most common approach is a "Code Component" which is a Tridion schema with a single plain-text field that's set to 20 - 30 rows. CSS and JavaScript are literally copied and pasted into the field. A component template written in Razor Mediator for Tridion (or DWT for that matter) renders the single field and the output is a .css or .js file.
In one implementation, we added metadata to our code schemas to allow us to toggle obfuscation and minification. This required us adding .net TBBs that could of course execute these tasks.
We would create CSS and JS page templates whose only job was to render the one field from our code components. Essentially this did the job of concatenating CSS or JS into a single .css or .js file.
I used this approach in Tridion R5.1 - 2011. It is an old approach that I haven't seen in modern implementations; it worked when we were publishing JSP or HTML pages from Tridion to a file server.
Downsides:
- Doesn't work great when you're not publishing static files
- Risk of Transcription errors in copying and pasting (yes, really)
- weird results if CSS/JS isn't well written; that page template lets you set the order of code components, and if code is poorly written, some styles or JS blocks could overwrite others or not work if one thing depends on another
Upsides:
- Easy to implement
- "Code as content". Some organizations have strict change control processes and treating code as content means they can bypass those processes.
CSS / JS as Binaries
This is just a spin on the previous example, but the idea here is that you add .css and .js mime types to Tridion and allow them to be uploaded as binaries. This saves the pain of transcription errors from copy and paste.
Publishing is then simplified as you publish assets directly from Tridion.
Downsides
- Still a "code as content" scenario, though risk of transcription errors is simplified.
- renaming a binary is all sorts of problematic. It could result in getting on the server to manually delete the .css file (or it did back in my day). It could also result in a broken site.
Upsides
- Easy to implement
- less likely to have copy-pasta errors than the other option
I've done both of these scenarios. I've also had a case where we created a special TBB to execute a CSS preprocessor in Tridion, so we could have SASS/SCSS in the CMS.
There are strong downsides to these approaches. Most importantly, you'd want to make sure that you can actually set certain page templates to publish as static files and not go to the broker (to be treated as actual content).
In the "CSS/JS as binaries" approach, they'll be treated like images, videos, and PDFs. You may not want that.