[CFG-1660] new ui for snyk iac describe

[moadibfr]

• Follows CONTRIBUTING rules

What does this PR do?

This PR update the snyk iac describe output with new ui by the design team.
(https://miro.com/app/board/uXjVOVYR5zg=/?share_link_id=306344151216)
This is a first iteration for the ui.

Where should the reviewer start?

Sorry about that but I made some refactoring to not have everything inside a single big typescript file, I hope this won't make the reviewing too painfull.
The pr introduce some change in drift.ts for the logic about driftctl first run output handling (mainly to use driftctl fmt only for html output).
Main addition will then be inside drift/output.ts.

What are the relevant tickets?

https://snyksec.atlassian.net/browse/CFG-1660

Screenshots

[craigfurman]

Full disclosure: this isn't the deepest review I've ever given. It's not a rubber stamp either - basically, all I've done is test this out, and then scan through the overall code structure and tests.

This was a bit tricky to review due to the combined refactor (a good refactor though), and functional changes. Ideally these would be in different commits. But I know 2 different people worked on it at different times, so no big deal.

Overall, LGTM! But perhaps get one more set of eyeballs on this, it's a large patch.

Non-blocking suggestion that's probably better for a follow-on: instead of having lib/iac/drift.ts and lib/iac/drift/ separately, we could have a single directory lib/iac/drift/, with a thin public interface in index.ts. I'm no TS expert, but AFAIK index.ts is a special case that can be imported by the name of its parent directory.

[wbeuil]

Non-blocking suggestion that's probably better for a follow-on: instead of having lib/iac/drift.ts and lib/iac/drift/ separately, we could have a single directory lib/iac/drift/, with a thin public interface in index.ts. I'm no TS expert, but AFAIK index.ts is a special case that can be imported by the name of its parent directory.

That's a pretty good observation here Craig, I didn't think of this one and I 100% agree with you.

[ghost]

Approving as there's not much choice around jsondiffpatch. Please be aware though that if jsondiffpatch or its dependencies have vulns, IaC will need to find an alternative or fork the project to resolve it as an incident. It might be worth IaC forking it now, publishing a fork, and using it here to avoid any potential malicious releases in the future.