It's impossible to know everything that's going on in a codebase - not that different from work, even more so for an open source project where you aren't reviewing every single PR or know about each aspect or part of the code.

We try to have team leads for different packages/areas which are mostly determined based on interest/history github.com/babel/notes/blob/master/2017-04/april-….

We have to invest in getting more people involved so that we can get more reviewers ultimately.

You can find the time if it's (hopefully) fun enough to do, otherwise live your life with other hobbies, family, friends,et c.

I'm not... but I've heard rumors that @hzoo is 🤖

i think the last one I coded up was to let me checkout Github PRs locally: gist.github.com/jridgewell/a93ca90c53183a6a3ba939…

I don't install a lot, https://github.com/junegunn/fzf?

Vim/MacVim. I learned to code in notepad, then switched to TextMate and stuck there for years. In college, I was too scarred by Eclipse and Java to ever try an IDE again.

I've always been using Sublime

I use Sublime 3.x for general stuff, with vim for in-terminal editing like git rebase -i and such.

There is https://gitlab.com/Rich-Harris/buble which is "smaller" but I don't think it's use case is the same. There is almost no configuration (not a bad thing at all) so no custom plugins, and it only compiles performant ES5. It's scope has expanded a bit (used to only be ES6, but now JSX, and people will continue to ask for more), and tries to compile to readable ES5 rather than be spec compliant.

However like any open source project you need a lot of maintainers to continually update it over the months/years. If someone wants to make something new instead, that sounds fine but depends on the goals and why you wouldn't contribute back to Babel already or refactor internally. No, I don't really see it happening, it's already hard enough to maintain Babel as is 😛

This is similar to hashnode.com/ama/with-babel-team-cj7awmk5e00ij54w…. It might but we try to make the default as spec compliant as possible so the things in spec might be too slow to add in.

In Babel 7.x we're adding support for a .babelrc.js file, so you can potentially programmatically build up the config you'd like based on environmental variables, to try to address cases like this more easily. Feel free to join our Slack if you want to chat more.

https://github.com/babel/babel-preset-env#loose - not as spec compliant, smaller output, may be faster. Try it in the REPL

You should already be getting a stack trace and the exact source code that causes the issue. If you're asking about badly transformed code (as in, the output is incorrect), then you'd have to do some digging like disabling plugins 1 by 1 until you track down the offender.

We don't have a specific log. Generally if an error is encountered, Babel will throw an exception, and it would be up to whatever is calling Babel to handle that. Usually that means it will be displayed in the console.

not sure what "bootstrap" code is, but I assume you mean helper methods. If it's the same then gzip covers it and otherwise you can use babel-plugin-transform-runtime

Definitely recommend checking out babel-plugin-transform-runtime. Specifically, only enable helpers and disable polyfill and regenerator.

Same as hashnode.com/ama/with-babel-team-cj7awmk5e00ij54w…. Which ones aren't supported? https://github.com/babel/proposals pretty sure we cover most if not all, it's definetely not a few haha?

We follow the TC39 proposal process, mainly. Anything that's been accepted as a stage-0 proposal by TC39 (and was presented to the committee or has a clear understanding of the semantics). We've tried to outline this at babel/proposals

There are a few primary factors that come to mind:

• Proposals that are not syntax-related are usually left up to core-js to polyfill, and some new features just can't be polyfilled
• We're a volunteer team, so someone needs to come forward with the interest to implement a given proposal, and ideally keep it updated.
• Some stage 0 proposals are expected to iterate quickly, which it less likely that someone will want to maintain it.

An invaluable resource in learning about how Babel plugins/transforms work is James Kyle's awesome babel-handbook.

Also, be sure to examine the plugins that are part of Babel and play around with astexplorer... they're both fantastic ways to learn as well.

As always, feel free to join our Slack if you need help or have any questions!

Hard to answer in terms of a specific "module", but a couple ideas:

• Check out any issues (especially those tagged with beginner-friendly)

• Anything related to documentation or the website

• Do you use Babel? Have you set it up yourself? We'd love to improve the developer experience overall, which includes both contributing to the code base as well as usage.

Definitely, though it'll be very hard to quickly translate 100% of jQuery code to just JS. This is because babel really shines as a syntax transformer (where crystal clear what's intended to happen in source code) vs jQuery which is a runtime library (which it's impossible to handle every case, because you can do crazy things in JS at times).

But if you're looking for something as simple as transforming $.each(array, () => {}) to array.forEach(() => {}, there shouldn't be any issues at all. Try checking out babel-codemod

Yeah you could use it as a codemod like Justin said to cover the 90% usecase and then manually convert the rest of it that isn't worth trying to code (which is advice for codemods in general).

The older ways work fine, and there are a lot of tutorials about them! I think there is a lot of advice on this but people like to say you may need to feel the pain in order to know why you would use the new thing. I don't think it matters that much: if you think it's too complicated to do something new, stick with what works. Chasing the new thing is tiring, unless using it is actually helpful enough?

Not everyone "has" to use the latest syntax or Babel

There's nothing wrong with using new standardized (as in, accepted and official JS syntax and runtime code). The ones you list are prefect examples of official code. Promises are everywhere, and essential to understanding async in JS. Awaits are well on there way to becoming best practice (and mandatory) learning, too.

But be careful with "experimental" codes that are not fully standardized (still in the proposal process, per the TC39).

Yep 😎 ! we already landed this for 7.0 with the help of the Typescript team. (It took a lot of work on their part, and a lot to review for us), so look out for a blog post/guide soon on how to make this work.

Basically, babel-preset-typescript will work the same as babel-preset-flow to remove the types from your code.

I think I'm the closest to being officially sponsored. I'm a Google engineer that spends my 20% time working on babel, and my direct team donates $100 on top of that.

@hzoo is a Behance engineer, and I think he spends roughly 50% of his time on babel?

Other than that, we're all unpaid volunteers. There's some backers on opencollective.com/babel, but not nearly enough to sponsor a full time engineer.

A couple of Babel's contributors are able to work on Babel part-time at their day job, which helps keep things moving. Otherwise our team is primarily volunteers. Babel currently accepts donations on https://opencollective.com/babel, but there's an open question around how best to reinvest those donations into Babel's community to keep things going.

For me, probably class private syntax. Any time I have to write a library I want to keep the implementation details hidden, and manually using WeakMaps isn't very ergonomic. Even in Babel's own codebase, it gets very unclear what is and is not supposed to be a publicly-accessible property.

(Maybe it's weird) I'm not particularly excited about any of them 🙂 , same with the ones we've already landed

Optional chaining and slightly do expressions.

I think it is mostly a question of which parts of compilation you want to learn. Babel is a pipeline for source-to-source code transformation, which means it is suited well for cases like compilation of ES* features. Most low-level compiler toolchains are going to do a lot more than that because they are converting from source code into a lower-level representation, whether that's LLVM's IR or bytecode or assembly. For a small overview of Babel you might consider looking at github.com/thejameskyle/the-super-tiny-compiler

Just gave a talk with that title 😛 github.com/hzoo/so-how-does-babel-even-work, https://github.com/hzoo/maintaining-an-oss-project, and our contributing guide github.com/babel/babel/blob/master/CONTRIBUTING.md.

Check out github.com/thejameskyle/the-super-tiny-compiler, https://github.com/thejameskyle/babel-handbook

There're no internal discussions on it yet, but it's something I've thought of tackling a few times. I've written a few advanced introspection features for personal projects that break down at the module boundaries due to babel being only a per-file transformer, and there are definitely other cool things that could be accomplished with a full project level transform.

Just don't expect it in the short time, though. We're already fully loaded just trying to keep up with the syntax transforms.

Busy and tiring :D I'm currently between jobs, but when I was working full-time it was definitely a tiring balancing act. I was generally triaging issues on the bus to work, helping on Slack when I had a free moment during the day, and then going home after work to fix issues and respond to anything that had come up during the day.

For me, my passion for side projects rises and falls. Some weeks I'll spend several hours at night reviewing and coding. And others I'll have no desire to look at my computer, let alone review someone else's code.

It definitely helps to be given time at work to contribute to open source work.

As both a new dad and startup co-founder, I often feel lucky to have even a few spare moments to help on the project where I can. I'll also echo Daniel's sentiments: one of the nicest parts of working on Babel is working alongside the community and everyone on the team.