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.
Thank you for your reply. I should have pointed out that with JS I also mean TS. We write everything in TS which gets transpiled into JS.
About your approach. I'm not sure if this is applicable to our situation. The problem is not only the complexity but also a cost and human resource matter. If some updates could be done automatically, the cost could be held down.
However I totally agree with you on the reduction complexity.
I also write TS. Here is my solution in my personal project that would never fly at work.
In your tsconfig.json set:
* alwaysStrict: true
* noImplicitAny: true
* strictFunctionTypes: true
Then I go a step further and wrote my own ESLint rules to:
* eliminate classes
* eliminate this
* eliminate bind, call, and apply
* eliminate addEventListener
* eliminate try/catch
I also use typescript-eslint package to lint against the TypeScript directly.
That sounds draconian but it removes a tremendous amount complexity, laziness, and stupidity. Everything comes strongly typed without a bunch of guesswork.
Comments
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.
Thank you for your reply. I should have pointed out that with JS I also mean TS. We write everything in TS which gets transpiled into JS.
About your approach. I'm not sure if this is applicable to our situation. The problem is not only the complexity but also a cost and human resource matter. If some updates could be done automatically, the cost could be held down. However I totally agree with you on the reduction complexity.
I also write TS. Here is my solution in my personal project that would never fly at work.
In your tsconfig.json set:
* alwaysStrict: true
* noImplicitAny: true
* strictFunctionTypes: true
Then I go a step further and wrote my own ESLint rules to:
* eliminate classes
* eliminate this
* eliminate bind, call, and apply
* eliminate addEventListener
* eliminate try/catch
I also use typescript-eslint package to lint against the TypeScript directly.
That sounds draconian but it removes a tremendous amount complexity, laziness, and stupidity. Everything comes strongly typed without a bunch of guesswork.