This happens to me quite often (I'm a Front-end developer):
The client needs something done, either some adjustment to their sites, functionality added or changed, "simple styles", but then they don't have any source code, they only have the minified version of all the files or even worst a super compressed ALL-IN-ONE file with javascript and CSS bundled in a messy code.
You have to deliver, so what do you do? Usually, I just create a new file, add the code, a lot of !important on each class, a bunch of #selectors, but that just makes it messier and unmaintainable for any future developer who has to fight the code, that includes my self sometimes.
New with file with overrides. Every time.
If I'm handed minifed code and expected to make magic happen, I'm not thinking about the next developer after me. Usually these projects spawn from bad clients or bad designers and the conflicts they tend to create (read: not your problem).
Your only goal: Make sure the job gets done as quickly as possible. We're cutting losses here. If the client cared about "future-proofing", "clean code", or "developer experience", they wouldn't have this issue in the first place (or would just pay for a recode -- knowing in the long run it's better than using frankenstein'd code).
If the changes are so substantial that you're on the brink of recoding it from scratch yourself (because it's easier at that point than playing around with overrides) -- it's time to convince the client they need to pay for a new project, not a revision. It's easier when you work by the hour, and you can show them how much time was wasted so far vs how much time could be spent from scratch.
Or if you know you'll have to dig into the rat's nest again, leave the project organized for your own sanity. Otherwise? Slap some !important in there and wait until the client requests a proposal for a redesign.
Eugh, there's never a good reason for that scenario.
Get started by prettifying the code, looking for libraries, and generally try to work out the general age/era of the code. Half of it might be libraries, which you can separate out to get to the actual bespoke stuff.
The CSS and HTML should be pretty readable since stock minification usually doesn't rewrite the names of class and ID attributes. JS is a messier situation, particularly if the methods have been minified away. But you should at least be able to find selectors and trace where they are used, which might give you some hints for the DOM stuff.
If you have piles of minified business logic, it's probably time to bail out. It's going to be too risky to do much in there.
And charge by the hour for all of it ;)
Jason Knight
The less code you use, the less there is to break
I take the source and pretty print / run a beautifier on it, which mostly reverses the process.
Though the client not having the originals just makes me wonder what the original DEV thought they had to hide -- I would question the competence of the entire process and would start digging deeper to see how far the rot goes.
... and if there are other deep-rooted issued, that's when you tell the client they were hoodwinked and bamboozled, suggesting a rewrite from scratch.