SyntaxError: Unexpected character '@'

[vjpr]

Issue description or question

Mon, 11 Mar 2019 00:23:32 GMT wallaby:processor Running 1 processor(s) for xxx/ZoneService.ts
Mon, 11 Mar 2019 00:23:32 GMT wallaby:processor Finished running one processor for xxx/ZoneService.ts
Mon, 11 Mar 2019 00:23:32 GMT wallaby:project Processing compiled xxx/ZoneService.ts
Mon, 11 Mar 2019 00:23:32 GMT wallaby:project Instrumenting xxx/ZoneService.ts, via process pool: true
Mon, 11 Mar 2019 00:23:39 GMT wallaby:project Error: Failed to parse xxx/ZoneService.ts, SyntaxError: Unexpected character '@' (41:39)

ZoneService.ts uses a decorator.

What is causing this issue? I am using Babel to compile my TS with an override in babel.config.js.

  const tsOverrides = {
    test: /\.(ts|tsx)$/,
    presets: [
      ['@babel/preset-env'],
      ['@babel/preset-react'],
      ['@babel/preset-typescript', {isTSX: undefined}],
    ],
    plugins: [
      ['@babel/plugin-proposal-decorators', {legacy: true}],
    ],
    include: p => {
      //console.error({asTS: p})
      return true
    },
  }

I also have a tsconfig.json file, but it doesn't seem to be reading it.

[NikGovorov]

Hi @vjpr ,

Could you please share your wallaby configuration file, tsconfig.json, babel.config.js and package.json?

Thanks.

[vjpr]

It's too complex.

Should tsconfig.json be used when compiling? EDIT: When using babel it doesn't: babel/babel#9028

At what stage of does the Failed to parse error occur? Is it during compile-time or runtime?

What is being parsed? Is it the original folder in the wallaby cache dir?

Is there a way to debug this? Maybe with a pre or post processor?

[ArtemGovorov]

Should tsconfig.json be used when compiling?

It depends on your Wallaby config. Could you please provide it as well as tsconfig.json, full babel.config.js and package.json (devDependencies should suffice)?

At what stage of does the Failed to parse error occur? Is it during compile-time or runtime?

Compile time. If it was runtime, there'll be some messages in the log saying about started test run.

What is being parsed? Is it the original folder in the wallaby cache dir?

It depends on your Wallaby config/project structure.

[vjpr]

Issue seems to be that @babel/preset-typescript doesn't support constructor parameter decorators.

microsoft/ReSub#98
babel/proposals#13

@Service()
export class FooService extends BaseService<Asset> {
    constructor(
        @OrmRepository() assetRepository: AssetRepository,
        @EventDispatcher() eventDispatcher: EventDispatcherInterface,
        @Logger(__filename) private log: LoggerInterface
    ) {
        super(assetRepository, eventDispatcher)
    }
}

I wish there was more error information. Tracking down Wallaby errors always takes forever. Can't you provide the babel compile stack?

[ArtemGovorov]

Tracking down Wallaby errors always takes forever.

In your case it doesn't look like Wallaby related error. If I understand the issue correctly, you'd be able to reproduce the same one when running your testing framework from CLI (without Wallaby).

Can't you provide the babel compile stack?

I checked and unfortunately there is no Babel stack, because there's no error raised from Babel. Babel simply ignores the decorator, and not throwing any errors in this case.

[vjpr]

@ArtemGovorov I'm trying to catch the error so I can give the user a hint of how to fix it.

The file is not being written to the instrumented directory. I think this means that it is failing in the instrumentation phase which is done by Wallaby's black-box.

Tue, 12 Mar 2019 14:05:08 GMT wallaby:project Error: Failed to parse xxx/Service.ts, SyntaxError: Unexpected character '@' (53:37)
    at emitTwo (events.js:125:13)
    at process.emit (events.js:213:7)
    at emit (internal/child_process.js:774:12)
    at _combinedTickCallback (internal/process/next_tick.js:141:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)
    at /Users/Vaughan/Library/Caches/IntelliJIdea2019.1/wallaby/wallaby/server.js:18:29663
    at _rejected (/Users/Vaughan/Library/Caches/IntelliJIdea2019.1/wallaby/wallaby/node_modules/q/q.js:864:24)
    at /Users/Vaughan/Library/Caches/IntelliJIdea2019.1/wallaby/wallaby/node_modules/q/q.js:890:30
    at Promise.when (/Users/Vaughan/Library/Caches/IntelliJIdea2019.1/wallaby/wallaby/node_modules/q/q.js:1142:31)
    at Promise.promise.promiseDispatch (/Users/Vaughan/Library/Caches/IntelliJIdea2019.1/wallaby/wallaby/node_modules/q/q.js:808:41)
    at /Users/Vaughan/Library/Caches/IntelliJIdea2019.1/wallaby/wallaby/node_modules/q/q.js:624:44
    at runSingle (/Users/Vaughan/Library/Caches/IntelliJIdea2019.1/wallaby/wallaby/node_modules/q/q.js:137:13)
    at flush (/Users/Vaughan/Library/Caches/IntelliJIdea2019.1/wallaby/wallaby/node_modules/q/q.js:125:13)
    at _combinedTickCallback (internal/process/next_tick.js:131:7)
    at process._tickCallback (internal/process/next_tick.js:180:9)

Is there a way to catch this error (Failed to parse during parsing in instrumentation phase)?

And how to debug it - because the user doesn't know what parser Wallaby is using...

---

So seems you are using acorn and a bunch of plugins to parse during instrumentation phase. It might be handy to give the user some more details about what is causing the error. E.g. Failed to parse doesn't really tell user anything, and the only option is to create a support request.

You should say something like:

Your compiled code failed to be parsed by Wallaby during the instrumentation phase (which uses acorn and some plugins).

Please check your compiled code can be parsed by acorn (you can wrap compilers) to check the compiled output. Try paste it into https://astexplorer.net/ with parser set to acorn.

If you are using Babel, potentially there is some syntax that is not recognized and is being passed through without generating a syntax error, that is then not parseable by acorn.

Could we also show the "inner error" stack trace from the Acorn parser? This would allow easy debugging of the exact source of the error. EDIT: Looks like the _cleanStack call is removing all the useful information. Could we have Wallaby config option to disable _cleanStack? Or maybe when debug is enabled, print the full stack on errors.

---

I've come across similar errors many times, and have always been left scratching my head and blindly trying things.

---

Also, on the postprocessors page, it lists the processing pipeline as so:

compilers
instrumentation
preprocessors
postprocessor
test run

Is it true that instrumentation comes before preprocessors?

[vjpr]

Have filed issue with Acorn to provide better error message for this particular case: acornjs/acorn#816

[ArtemGovorov]

Thanks for your feedback. We have improved the error reporting for instrumentation failures in the latest core version.

[ArtemGovorov]

This is how the errors from the instrumentor look now:

[ArtemGovorov]

Sorry, the change had not made it through in yesterday's build, but the latest 1.0.665 version contains it.

[vjpr]

I appreciate the improvement, its definitely a step in the right direction.

But its still next to impossible for a user to resolve these errors by themself. I think it would be worthwhile adding some of my suggested comments here to an FAQ page.

Not knowing that acorn (which doesn't support a lot of ES.next stuff) is being used to parse the compiled files, and without a real stack trace (and no mention that the stack trace in the console output is has been trimmed) it really puts the user in a tough situation.

[ArtemGovorov]

Thanks for the feedback. We have added some of your comments to the FAQ section.