Lewis

@concavelenz As I understand it, this was an issue regardless of build - it was just an issue of extended Unicode characters not accurately being counted as valid identifier parts,...

@rishipal Thank you for your help on this PR. Was this merged internally? Sorry to bother!

Following for updates. This is expected if `language_in` and `language_out` are different (transpilation will still be necessary), but unfortunately this persists even if you manually specify the same output for...

@concavelenz After spending a few days diving through the source I found the `NO_TRANSPILE` language_out flag, which seems to be the magic bullet for situations like this.

@AshleyScirra Yeah, I only found it in passing. The only public reference I can find to it is @brad4d's issue https://github.com/google/closure-compiler/issues/3256. See the output for `google-closure-compiler -O WHITESPACE_ONLY --formatting PRETTY_PRINT...

@AshleyScirra There isn't supposed to be one - same input/output language should also imply no transpilation. It doesn't end up being 100% coverage, but it does work usually: `$ google-closure-compiler...

I can get output by manually supplying the specific package I am importing with `--js` and then ignoring errors with `--jscomp_off '*'`: ```shell $ google-closure-compiler -O ADVANCED --process_common_js_modules --module_resolution NODE...

Very sorry for not responding sooner @ChadKillingsworth, thank you very much for your notes. I see that you have been actively working on that utility as well, I would say...

This is probably going to be the focus of my future contributions Chad, is learning your `calculate-closure-chunks` tool and rolling it in / writing tests. I have still not read...

I would definitely say so. Setting both flags to `STABLE` by default, coupled with the internal difference between `STABLE_IN` and `STABLE_OUT`, leads to transpilation by default (even with `--WHITESPACE_ONLY` flag)...