search

salesforce / lwc

⚡️ LWC - A Blazing Fast, Enterprise-Grade Web Components Foundation
https://lwc.dev
Other
1.64k stars 392 forks source link

@Babel/preset-env included in SFDX project #1454

Open BriannaBrown-hub opened 5 years ago

BriannaBrown-hub commented 5 years ago

Is your feature request related to a problem? Please describe. I would really like to use some of the new javascript language features.

Describe the solution you'd like Is it possible to include the @babel/preset-env plugin in my local sfdx project?

Describe alternatives you've considered Having to live with an older javascript specification.

Additional context Thanks for your help!

diervo commented 5 years ago

Hi Brianna, which features are you looking for? I believe we support ES2018 so want to make sure is nothing we missed that should be there.

In case that what you are looking for are features that are not yet in Stage 4 (or are not fully supported in all browsers) we won't support them natively in the platform.

However you can certainly run babel yourself to transpile the features you want, and push the results of that transpilation to the platform.

There are a lot of customers doing something similar with Typescript where you remove the types and then you push the result via sfdx (similar story where we can't support TS due to future breaking changes)

I will keep this issue open until you clarify the features you are missing or til we can help you setup you flow.

rtm commented 5 years ago

Could you elaborate on "can't support TS due to future breaking changes"?

On Fri, Aug 16, 2019 at 5:20 PM Diego Ferreiro Val notifications@github.com wrote:

Hi Brianna, which features are you looking for? I believe we support ES2018 so want to make sure is nothing we missed that should be there.

In case that what you are looking for are features that are not yet in Stage 4 (or are not fully supported in all browsers) we won't support them natively in the platform.

However you can certainly run babel yourself to transpile the features you want, and push the results of that transpilation to the platform.

There are a lot of customers doing something similar with Typescript where you remove the types and then you push the result via sfdx (same story where we can't support TS due to future breaking changes)

I will keep this issue open until you clarify the features you are missing or til we can help you setup you flow.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/salesforce/lwc/issues/1454?email_source=notifications&email_token=AAAF6RZSR6YN243YOPW5FETQE473DA5CNFSM4IMNPKR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4P7CPI#issuecomment-522187069, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAF6R6KJFGE7VOD4WOMYWTQE473DANCNFSM4IMNPKRQ .

diervo commented 5 years ago

Let me be clear that this is a Salesforce platform restriction, not an OpenSource one, you can do whatever build steps and use whatever superset of JS you want in LWC OSS. This issue was filed in relationship with SFDX which is a Salesforce Platform specific question.

To clarify your question: Typescript team will not guarantee (not for us, not ever) that they will not introduce breaking changes - which makes sense since they have to evolve their system, but that doesn't work with our business model.

Let me give you an example (this assumes you are familiar with the Salesforce platform):

Let's say we allow you to push your components to our Platform natively in Typescript, assume we are using Typescript compiler version 3.4.5.

At some point we would want to upgrade Typescript to 3.5, but they introduced breaking changes: https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#typescript-35

So the very code you wrote in 3.4.5 will now be broken if we upgrade the TS compiler, which is something that is unacceptable for our customers - We have SLAs that guarantee that your code will not break and it will run forever (is not technically forever but kind of...).

We can't just tell our customers "Hey sorry, you need to upgrade your code because we want to upgrade the compiler", nor we can't bear to support multiple compiler versions til the ends of time.

The same applies to features that are not yet standardized or implemented in all browsers we support. Like for example if we were to support optional chaining operator we will be committing to support that forever, regardless of if it makes it to the spec or not. So we have to be very careful every time we add support for new syntax on our platform.

To prove my point, here is an example of how to use Typescript with LWC OSS: https://github.com/diervo/lwc-typescript-boilerplate

If you wanted to use this in our platform, all you need to do is do a pre-build step removing the types (or for this issue whatever feature is not supported) and the push the resulting bundle to our platform.

BriannaBrown-hub commented 5 years ago

Thank you so much for the quick and detailed response @diervo. Please see below my response to your comments.

Hi Brianna, which features are you looking for? I believe we support ES2018 so want to make sure is nothing we missed that should be there.

Here's a few of the features we are using in other projects we'd love to pull into this one.

None of the above are need to haves but would be really useful to ensure that the salesforce development flow matches the rest of the team.

In case that what you are looking for are features that are not yet in Stage 4 (or are not fully supported in all browsers) we won't support them natively in the platform.

I believe the above examples listed have now reached stage 4 and are included in @babel/preset-env.

However you can certainly run babel yourself to transpile the features you want, and push the results of that transpilation to the platform.

This may be in an option for us, but we thought it was still worth asking if the capability exists as LWC already uses babel and we're wondering if there is a way to configure it directly.

So the very code you wrote in 3.4.5 will now be broken if we upgrade the TS compiler, which is something that is unacceptable for our customers - We have SLAs that guarantee that your code will not break and it will run forever (is not technically forever but kind of...).

We can't just tell our customers "Hey sorry, you need to upgrade your code because we want to upgrade the compiler", nor we can't bear to support multiple compiler versions til the ends of time.

This is a reasonable approach, I totally understand why you wouldn't want to impact other customers in this way. My ask would be that the code would check that a .babelrc file exists and if it does, to use that configuration instead. This could be done here in the code and wouldn't impact existing users. This would also allow us to hook into the salesforce environment without excessive configuration or build steps. This is the approach that Parcel takes.

Once again, thank you for taking the time to consider this request. It is much appreciated.

caridy commented 5 years ago

@briannabrownOE:

I believe the above examples listed have now reached stage 4 and are included in @babel/preset-env.

None of them are stage 4:

BriannaBrown-hub commented 5 years ago

@caridy thanks for the clarification. These are features our team is currently using, I hadn't realized they had not reached stage 4 as of yet. Thanks for bearing with me as I'm still learning about the world of TC39.