-
Notifications
You must be signed in to change notification settings - Fork 361
[wip] Babel support #39
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
Conversation
Thanks for the awesome start @Andarist! I think the only things on my mind here were to make sure we were on Babel 7 so we get the updated ultra-compact loose mode and support for blacklisting regenerator (so we can still use nodent or fast-async). |
@@ -168,6 +169,8 @@ function createConfig(options, entry, format) { | |||
let cjsMain = replaceName(pkg['cjs:main'] || 'x.js', mainNoExtension); | |||
let umdMain = replaceName(pkg['umd:main'] || 'x.umd.js', mainNoExtension); | |||
|
|||
const useBabel = !!pkg.babel || await isFile(resolve(cwd, './.babelrc')) || await isFile(resolve(cwd, './.babelrc.js')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking that, as long as we can get a default babel config that is as optimized as Bublé, we can just default to Babel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff happening in terms of babel@7 in terms of outputting better tree-shakeable code & more concise/performant code, but it's still a beta. Im pretty confident in it, we have a comprehensive test suite after all, so I'm using it all over the place - aint sure though if we should promote it just yet as part of other tool (microbundle
in this context) as it has potential to break some stuff. And also it might not be yet compatible with some other tooling as not every tool had an opportunity to catch up yet and provide support for it.
If we are gonna default to babel@7, Im wondering how do you plan to support babel configs? Or maybe you'd like to ignore it all along and just use internal, optimized one? Im not sure how the whole thing applies to your 0 configuration goal 😉
Personally I'd say it's better to read the real babel config, but then I'm not sure how we should "optimize" it. Mutating the input and i.e. parsing it to add loose
option to plugins & presets seems a little bit magical. If one specify his/her config we should just use it as is, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idea - we could possibly support babel config files without any magic, read the config files (only for validation) with some utility exposed by babel like this one and parse it (ideally we could just receive the result from babel in JSON) to warn people against using non-loose / costly stuff. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Andarist I spoke to Henry and I believe he mentioned they pulled the configuration parsing & lookup out of Babel into a standalone module. Maybe we can use that now?
+1 for warning, though it'd be nice to have a way to use a "stock" babel config and let microbundle tweak it into loose mode.
Actually there is a PR for nodent support in babel - babel/babel#7076 . So maybe once it gets merged in, we could just use it as default. |
Babel has a spetial way to handle named imports that is not spec compliant, I am not sure how bublé works but I just want to be sure you have that on mind in case you plan to always switch to babel (without .babelrc present or any other indication) |
@lrn2prgrm could you explain what do you mean by babel not being spec compliant on named imports? babel is trying to be as spec-compliant as possible by default (when i.e. buble is not trying to do that) - the only pain point is sometimes interop between esm and cjs, but that's because of how both module formats work |
Hello guys, do you still plan to support babel? |
@abusada yes, I very much want this to happen, I'm just slammed with work lately |
@Andarist maybe i can help, if i know what direction the maintainers would like to go in, i mean, Zero-configuration all the way or support i like your idea
and i think it's the best way to move forward with supporting babel! |
In general I think this is what would be best (some of those poinst I have already stated in this thread, so might be repetitive):
@abusada if u want to work on it, we'd certainly appreciate the help! just let us know, we can discuss this in greater detail (if needed) on some slack (or smth else) too |
We'd need to run some tests to see output size of Babel vs Buble for basic stuff. For async/await there are a few decent babel plugins we could switch to. |
Any updates on this? I'd really like to be able to use class properties in my code. |
++ for that, missing class properties on classes too 😅 |
This is waiting on Babel 7's official release: |
@developit Is there any chance of having a pre-release based on 7.0.0-rc.1? |
Maybe! |
that would be really nice, I could test this pre-release in a internal project ☝️ |
Update: I've run into a few bugs with Nodent. I think moving from Bublé to Babel and switching from Nodent to |
Will it fix #86 ? |
@tryzniak yes. |
I'm sure you've heard, but Babel 7 is out https://babeljs.io/blog/2018/08/27/7.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs to handle useTypescript
cases as well as options.jsx
for babelrc
So excited for this! |
@developit How is the coming along? Really anxious to use babel with microbundle! |
Just need a default config I'd say |
Hi! I was discussing this project at transitive-bullshit/create-react-library#104, where we're looking for an abstraction over Rollup, and wanted to check in about the status of Babel support in microbundle. It looks like as of today:
I have a couple questions:
|
IMHO it's time to revive this - the main blocker was preferring nodent over babel's default async functions transform. It got removed lately though in favour of babel transform so I'd say we could finally switch over to babel@7. |
+1 on reviving this PR. The code in master is already using babel@7, so it should be straightforward to build on that. It doesn't support custom babel configs yet. Note that many babel transforms generate larger output than bublé which is why the latter is used instead of babel's preset-env. |
Seems like we have a new pr for this |
Just a starter - need to figure out what else needs to be done to support this within your vision's frame 😉 any particular requirements come to your mind?
fixes #25