From 9b77ed9a293c538ec3eb5160bcb933e012ce517f Mon Sep 17 00:00:00 2001 From: Johannes Ewald Date: Mon, 9 Apr 2018 20:49:49 +0200 Subject: Replace babel with a regex-based transformation This regex replacement is not 100% safe because transforming JavaScript requires an actual parser. However, parsing (e.g. via babel) comes with its own problems because now the parser needs to be aware of syntax extensions which might not be supported by the parser, but the underlying JavaScript engine. In fact, rewire used to have babel in place but required an extra transform for the object spread operator (check out commit d9a81c0cdacf6995b24d205b4a2068adbd8b34ff or see https://github.com/jhnns/rewire/pull/128). It was also notable slower (see https://github.com/jhnns/rewire/issues/132). There is another issue: replacing const with let is not safe because of their different behavior. That's why we also have ESLint in place which tries to identify this error case. There is one edge case though: when a new syntax is used *and* a const re-assignment happens, rewire would compile happily in this situation but the actual code wouldn't work. However, since most projects have a seperate linting step which catches these const re-assignment errors anyway, it's probably still a reasonable trade-off. Fixes https://github.com/jhnns/rewire/issues/132 --- testLib/throwError.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'testLib/throwError.js') diff --git a/testLib/throwError.js b/testLib/throwError.js index ffb6a71..e85ea36 100644 --- a/testLib/throwError.js +++ b/testLib/throwError.js @@ -1,4 +1,4 @@ -// Using const here because we know that Babel will transform that part +// Using deliberately const here because we know that we're transform const to let const test = 1; module.exports = function () { -- cgit v1.2.3