Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First ugly pass of using babel (0.9.5) #3333

Closed

Conversation

adamhathcock
Copy link
Contributor

I moved the existing code to src/ then ran:
./node_modules/.bin/babel src --out-dir .
then manually deleted the changes in vendor.

I realize this is ugly but I don't know what the build process is like. Would using Babel to manage the javascript output be something to consider?

Fixes #3203

@stsrki
Copy link
Collaborator

stsrki commented Jan 17, 2022

So this walks every JS file and transpile it to ECMA compatible versions?

@adamhathcock
Copy link
Contributor Author

Yeah, that's the basic jist of it. It's doing ES5 level javascript I believe.

@stsrki
Copy link
Collaborator

stsrki commented Jan 17, 2022

I appreciate the effort. But, I have several problems with this approach.

  1. It changes the source files which practically strips all formating, new JS syntax, and best JS practices making it harder to maintain.
  2. It introduces babel which I also don't like because it is another new tool that we had to have in order to transpile. Personally, I've escaped from React world mostly because of the pain of working with it, and webpack also.
  3. Since all the sources are changed it would be impossible to merge it into master without introducing major bugs. We did a lot of work since 0.9.5.

What I would do instead is to find the actual weak point in our current JS files and modify them. This approach could make that happen by automating and then comparing the result. That is I think the most painful way to do it.

@adamhathcock
Copy link
Contributor Author

I don't disagree with your assessment, I hate javascript (which is why I'm using Blazor 😄 ) but I don't know if there's a more maintainable way. I still think Babel is the least painful with the amount of javascript being used but happy either way

I used es-check at first to see what's "bad" and perhaps a ES6 level would be fine but I don't know. It goes beyond my javascript expertise. Classes can't be used at that level (which makes sense for one of the errors I've seen)

I'm happy to contribute time to fix this but I'd probably need someone else to bootstrap the strategy desired. I'd provide the grunt work of conversion.

@stsrki
Copy link
Collaborator

stsrki commented Jan 18, 2022

es-check might be a good approach. It is just an extra step to make sure we're on the good track. We just need to agree on the minimum ES version to support it.

For reference. https://caniuse.com/?search=es6

@stsrki
Copy link
Collaborator

stsrki commented Jan 18, 2022

I'm experimenting with es-check. It works quite well I must admit. So far most of the errors come from the usage of const/let, class, and spread/rest operators.

Now the difficult part. Should we support ES5 or ES6? 🤔

@adamhathcock
Copy link
Contributor Author

Looking at https://caniuse.com/es6 that's probably good enough?

Going back to ES5 seems ancient

@stsrki
Copy link
Collaborator

stsrki commented Jan 18, 2022

Close in favor of #3336

@stsrki stsrki closed this Jan 18, 2022
@adamhathcock adamhathcock deleted the babel-javascript branch January 19, 2022 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants