Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Consider moving from fly-esnext to fly-mz

See original GitHub issue

Fly currently has a hidden feature in which it attempts to pass the flyfile.js through fly-esnext for transpiling in order to add support for ES2015 features.

However, there’s a number of issues with fly-esnext, the biggest one being inconsistent feature support due to the use of RegExp-based replacements. I know that it manages to have better performance than a parser-transpiler based version due to this but there have been many complaints of the lack of feature support (like how it fails with different spacing, variations of code, or that it runs the regexp engine 5 times in order to transpile the code - and the regexp engine is already so slow).

There are also certain other issues like the fact that the flyfile is run inside of a separate V8 sandbox and therefore does not have certain node features (like console is undefined).

However, it seems that the author of that project is insistent on keeping up the regexp way for the performance benefit. I wanted to propose the alternative to that package, a package which I just published called fly-mz. The API is exactly the same as what Fly expects from fly-esnext, but it uses babel-preset-env for the most optimal transpiling for the current version of node. It also fixes the sandbox issues.

I’ve currently added a hack to the postinstall script of fly-mz to use a symlink (fly-mz -> fly-esnext) in order to get Fly to work with the package.