A compiler transforms instructions from one language to another. You are wanting to produce an interpreter which is a different beast.
Neither of those will satisfy the problems you described. The problem, as you described and which is extremely common in large organizations, is a failure to scale. This is largely due to people making a series of really bad decisions independently and once the pieces are put together those pieces don’t play well together.
The solution to that problem is eliminating complexity. Complexity is easy just as simplicity isn’t. That means setting rules that will make people unhappy. They will call you draconian and do everything they can to spit on you because complexity elimination exposes all the things people do to find comfort in that which they find challenging. This needs to be done via automation as much as possible so prevent bias and really hammer in that nail.
Actually you asked this question at a good time! Using hn.algolia.com, which is this site's search function -
https://hn.algolia.com/?dateRange=pastWeek&page=0&prefix=tru...
I found this very recent post, which I knew I bookmarked somewhere, but didn't have the link handy!
Resources for Amateur Compiler Writers (https://c9x.me/compile/bib/)
336 points | kilodeca | 4 days ago | 88 comments
Hi,
Indeed it's difficult to find documentation and books between the low level stuff like the old flex/bison and high level tools like Xtext or even MPS.
For your use case I think you could simply write a set of eslint rules. This short document is a good start https://gist.github.com/sindresorhus/1656c46f23545deff8cc713...
https://astexplorer.net is recommended and a good resource.