3 ms·
Why don't you just run it on your target codebase and then run your test suite to make sure nothing is broken?
by iamleppert 8y ago
Why don't you just run it on your target codebase and then run your test suite to make sure nothing is broken?
- bastawhiz 8y agoI suppose I could, but then I'm running my tests twice (once against the actual compiler and once against swc). Compiling my code is necessary to run the tests anyway, so it seems a bit moot to go through the trouble. I could ditch "real" TypeScript compilation altogether, but then you're not building for TS anymore, you're building for the variant of TS that swc supports. Plus, I'm not writing unit tests that test the behavior of things like enums and decorators, I'm testing the business logic of my application. If the compiled code behaves strangely under abnormal conditions that wouldn't occur in the test environment, it's going to be a hell of a time for me to figure out what's going wrong.
- mhh__ 8y agoAlthough it works 99% of the time, I'm not a huge fan of "Just run the tests" style of ... testing. Unit tests are important, but I feel slightly insecure if I don't think about the process mechanically rather than as a black box. In this case your suggestion is a good one, obviously.
- underwater 8y agoOne suggestion I like is that open source projects include a TRADEOFFS.md file that details the technical decisions made on the project. Hiding that information means that by default consumers don't have the information they need to make an informed decision. This leads to better marketing beating out better technology and, more importantly, fractures in the community.