1

The numeric separator proposal, which allows us to say things like 30_000, is now implemented in lots of browsers, and is also handled by a Babel plugin, which is what this LWC message seems to be suggesting we use:

LWC1509: This experimental syntax requires enabling the parser plugin: 'numericSeparator'

I assume this is referring to @babel/plugin-proposal-numeric-separator, but when I add this to a babel.config.json it's still unhappy. Is there some way to enable this parser plugin? Or do we have to wait for this to be officially supported in the LWC compiler, like everything else? If we cannot specify the plugin, then what is the purpose of this error message, and shouldn't it instead say:

LWC1509: Sorry, you've chosen the wrong JS platform. Please wait until 2022 to use modern syntax like this.

2 Answers 2

3

LWC1509: Sorry, you've chosen the wrong JS platform. Please wait until 2022 to use modern syntax like this.

First, that's a cynical view point.

Second, such a statement would have to be #SafeHarbor bound, and that's generally more trouble than its worth.

Third, this feature apparently came around right around November 2020, which would have been very close to their Code Freeze Date for Winter '20 (I don't know the internals, but only security patches and bugfixes are allowed in the month or so leading up to release).

As such, there's no way they could have snuck that in at the last second, even if they wanted to. They're not a web browser developer that can arbitrarily release day-one packages; they have strict release cycles to help manage regression, etc.

Fourth, it'd have to make it in to LWC OSS before it could get in to Salesforce. If LWC OSS manages to get this in before the Summer '21 release's Code Freeze Date, then it's possible they can just patch it in.

Fifth, salesforce.com has generally decided not to support features that are experimental or subject to change. You can't even write custom decorators or wire services yet. While this is unfortunate, it's what we have to live with.

That said, not having that separator isn't really that big of a deal to complain about. I'd rather write 3e4 (which is supported) over 30_000 as a preferred syntax for larger numbers. It's easier for me to visualize this. Of course, that depends on the numbers you're talking about. If we need to encode 31_415_926, then I can see the value in it.

In fact, LWC doesn't even support all of ES8 or ES9 yet, even if browsers do.

As an aside, I'll ask around to see when/if this may be supported.

As a final note, it's also worth mentioning that a lot of things are walled off by Locker Service in Salesforce LWC. In addition to the usual things that other platforms have to worry about, there's a security review to make sure the change won't have any possible way of breaking LWC in a way that could allow security violations.

While this is a small change, there's always an abundance of caution when introducing seemingly small, benign features that could have security implications.

5
  • Thanks for your answer. I'm fully aware that I am beating a dead horse and that nothing I or any other developer says or does will change anything about this issue of supporting new JS features. Having said this, although I am not sure what you are referring to when you say "came around November 2020", this feature is at stage 4, and as such is for all practical purposes part of the standard, ratification and inclusion in the ECMAScript 2021 script a mere formality. It reached stage 4 in July 2020. 1/
    – kamezaburo
    Commented Jan 20, 2021 at 19:52
  • 1
    @kamezaburo Ah, I think I looked at the wrong resource. I do agree, technically, that if all browsers are already supporting this, and it's in Stage 4, it wouldn't be harmful to include it at this point. Still, they do have to manage things on a strict schedule, and I should have also pointed out that they only have so many "points" they can spend each release; it's entirely possible that it just doesn't have a high enough priority over critical security patches, etc, even if it's only a single point.
    – sfdcfox
    Commented Jan 20, 2021 at 19:55
  • 2
    It's hardly a justification for a missing feature like this that there are lots of other missing features. Nor is it a particularly compelling argument that they have long release cycles--this and other features have been in the works for a long time, and they could have been preparing. Finally, it is unconvincing to cite some kind of risk or security implications for a feature like this. The bottom line is that their roadmap does not prioritize JS spec compliance and usability. All I'm saying is, that's too bad. 2/
    – kamezaburo
    Commented Jan 20, 2021 at 19:56
  • 1
    @kamezaburo Indeed. I've spoken with people in the know, they feel like it'd be easy to add this support, and I've submitted an issue/ticket with the LWC team. If there's any other missing proposals, we can put them there, too.
    – sfdcfox
    Commented Jan 21, 2021 at 16:34
  • That's great, thanks for following up!
    – kamezaburo
    Commented Jan 22, 2021 at 0:19
2

I believe this is the kind of thing you will find on LWCs that are not supported on the platform. There's a difference.

Lightning Web Components do not necessarily need to be deployed within the Salesforce platform. In this case, you handle the source code and you have your own compiler. In this scenario you can set that flag and probably other ones.

When writing LWCs for the platform, however, the code will be compiled and deployed to Salesforce's servers, so they need to keep things working as smoothly as possible. There is little space for experimental things.

If you are talking about using the framework outside the platform you might want to ask this question on StackOverflow instead.

4
  • 2
    We do, at a general level, support lwc-oss. We can always deflect there if need be, but should not assume that as our default position.
    – sfdcfox
    Commented Jan 20, 2021 at 19:27
  • Thanks for your answer. This feature may be "experimental" in some narrow sense, but it's shipping in all major browsers already (in chrome for 18 months now!). It's not like it's real complicated or risky. It's just a one-line addition of a babel plugin to the LWC compiler code. I remain mystified why it takes so long to support such basic, useful things that developers on all other JS platforms take as a matter of course. I am developing for the SF platform, so it doesn't matter if their OSS version supports this. Color me disappointed.
    – kamezaburo
    Commented Jan 20, 2021 at 19:36
  • Remember that the "it's just a one-line addition of a babel plugin to the LWC compiler code" seems to - and might be - a small change, but if it is done on the server side, this might be something that either breaks something for Salesforce or simply isn't a priority at this time. The key word here is "scale". Once this is applied on Salesforce's servers, they'll have to provide support for this to all of their customers if something goes wrong. Commented Jan 20, 2021 at 20:56
  • @RenatoOliveira It's not anything done on the server side, AFAIK. It's a trivial lexical transformation carried out by another Babel plugin--which they are already using--that operates at compile time. There's nothing to "support". It's extremely difficult to imagine what this could possibly "break". Help me out. By definition, this is a completely backwards-compatible change because all ECMAScript changes are. Your logic would justify supporting no new JS enhancements whatsoever.
    – kamezaburo
    Commented Jan 22, 2021 at 0:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .