fix: remove word boundaries from decorator check regex

[yashank676]

Details

/\b(track|api|wire)\b/ tests false if track is with ANSI escape codes for color output in terminals e.g. \033[31;1;4mtrack\033[0m

Does this pull request introduce a breaking change?

• 😮‍💨 No, it does not introduce a breaking change.

Does this pull request introduce an observable change?

• 🔬 Yes, it does include an observable change.
• The user will now get LWC1198 error instead of LWC1007 for Babel decorator error consistently.

[salesforce-cla]

Thanks for the contribution! It looks like @yashank-aggarwal_sfemu is an internal user so signing the CLA is not required. However, we need to confirm this.

[wjhsf]

What is the motivation for this change? Please also add some test cases to demonstrate the changed behavior.

[yashank676]

@wjhsf The regex condition present was not able to search for the decorator due to ANSI format of the error code given to match, in cases like eg it was able to match the regex due to import statement present and hence threw 1198 error
but if we have anything else added after import statement (try adding a comment eg), the regex wont be able to match and 1007 error would be thrown which caused inconsistency.

[wjhsf]

When the LWC compiler encounters a babel error, it checks the message for the LWC decorators (api/track/wire), and provides a more helpful message if encountered (LWC1198, rather than LWC1007). However, it checks using regex word boundaries (\b), and babel uses ANSI escape codes (\x1b[39m) for formatting the how the error message is printed to console, causing the regex to sometimes report false, even though an LWC decorator is used. For example, \x1b[33m@\x1b[39mapi prints @api with a yellow @. This is a scenario that we should capture, but do not.

The actual decorator usage that causes the error seems to always be preceded by a color token. However, babel includes a few lines of code as context prior to the erroneous decorator usage. This means that whether we get LWC1198 or LWC1007 is dependent on that context. For example, if the context includes import { api } from 'lwc', then we will get LWC1198. If not, we will get LWC1007. This behavior is inconsistent and confusing.

---

Consider this class, which is not a component:

import { eschatology } from 'vermont'
export default class Bananaphone {
  @eschatology biggens
}

With the proposed change, the above code will fail to compile with "Error: SyntaxError: LWC1198: Decorators like @api, @track, and @wire are only supported in LightningElement classes." That's misleading, because neither the decorators nor LightningElement are involved in this scenario.

A better fix, here, would be to update the regex to account for the possibility of ANSI escape codes, so that we still only add the LWC context when actually relevant. We should not rely on any specific codes being present, as babel may change the color of their output at any time.

[yashank676]

Agreed to all the points, i am already looking into it and see if some regex can be made to handle that.

[yashank676]

@wjhsf i have updated the regex. Also, looks like updating unit test for this makes no sense as the issue we faced in previous regex was due to ANSI format in error, but in vitest it was a simple string error instead.

[abdulsattar]

This is brittle. Please just remove the \b from the original regex and it should be enough.

[yashank676]

@abdulsattar agreed that would also work but there could be a case like following:

import { eschatology } from 'vermont'
export default class Bananaphone {
  @eschatology wire
}

then this also throws 1198 instead of 1007 due to wire/api/track being the variable name.

[yashank676]

or even something that contains any of these words would lead to 1198.

[abdulsattar]

Yes, I imagined it would be the case. But, it's an acceptable trade-off. At worst, users are getting a little generic error (which is still related to decorators).

[yashank676]

sure, let me update it then.

[wjhsf]

The full sequence, as returned by the ansi-regex npm package, is /(?:\u001B\][\s\S]*?(?:\u0007|\u001B\u005C|\u009C))|[\u001B\u009B][[\]()#;?]*(?:\d{1,4}(?:[;:]\d{0,4})*)?[\dA-PR-TZcf-nq-uy=><~]/g.

Using that is definitely overkill for our use case. I think we should keep the original check, but relax it if we see the escape character (\x1b). We don't really care if the escape codes are properly formatted or not. The regex to accomplish this would be /(?:\b|\x1b\S*?)(api|wire|track)\b/.

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @yashank676 to sign the Salesforce Inc. Contributor License Agreement.

[wjhsf]

@yashank676 please make sure the CLA is signed and add two test cases to packages/@lwc/compiler/src/transformers/__tests__/transform-javascript.spec.ts.