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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[wip] Babel support #39

Closed
wants to merge 1 commit into from
Closed

Conversation

Andarist
Copy link
Collaborator

@Andarist Andarist commented Jan 9, 2018

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

@developit developit self-requested a review January 10, 2018 15:06
@developit
Copy link
Owner

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'));
Copy link
Owner

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.

Copy link
Collaborator Author

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?

Copy link
Collaborator Author

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?

Copy link
Owner

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.

@Andarist
Copy link
Collaborator Author

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).

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.

@corlaez
Copy link

corlaez commented Jan 30, 2018

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)
Reference:

@Andarist
Copy link
Collaborator Author

@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

@abusada
Copy link

abusada commented Apr 3, 2018

Hello guys, do you still plan to support babel?

@Andarist
Copy link
Collaborator Author

Andarist commented Apr 3, 2018

@abusada yes, I very much want this to happen, I'm just slammed with work lately

@abusada
Copy link

abusada commented Apr 3, 2018

@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 .babelrc?

i like your idea

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?

and i think it's the best way to move forward with supporting babel!

@Andarist
Copy link
Collaborator Author

Andarist commented Apr 5, 2018

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):

  • support babel@7 (drop buble entirely)
  • provide default config if user has no .babelrc/.babelrc.js/babel.config.js - there are new APIs in babel@7 for user config inspection
  • even if user has custom config then we can "validate" it and suggest i.e. using loose mode, or warn about costful transforms
  • not yet sure what about nodent

@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

@developit
Copy link
Owner

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.

@developerdizzle
Copy link

Any updates on this? I'd really like to be able to use class properties in my code.

@weslleyaraujo
Copy link

++ for that, missing class properties on classes too 馃槄

@developit
Copy link
Owner

This is waiting on Babel 7's official release:
https://babeljs.io/blog/2017/12/27/nearing-the-7.0-release

@developerdizzle
Copy link

@developit Is there any chance of having a pre-release based on 7.0.0-rc.1?

@developit
Copy link
Owner

Maybe!

@weslleyaraujo
Copy link

that would be really nice, I could test this pre-release in a internal project 鈽濓笍

@developit
Copy link
Owner

Update: I've run into a few bugs with Nodent. I think moving from Bubl茅 to Babel and switching from Nodent to babel-plugin-fast-async would be a good idea.

@tryzniak
Copy link

Will it fix #86 ?

@developit
Copy link
Owner

@tryzniak yes.

@developerdizzle
Copy link

I'm sure you've heard, but Babel 7 is out https://babeljs.io/blog/2018/08/27/7.0.0

Copy link

@ezekielchentnik ezekielchentnik left a 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

@gaui
Copy link

gaui commented Sep 9, 2018

So excited for this!

@taylorjdawson
Copy link

@developit How is the coming along? Really anxious to use babel with microbundle!

@ForsakenHarmony
Copy link
Collaborator

Just need a default config I'd say

@paulmelnikow
Copy link

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:

  1. Have the upstream blocks mentioned above been cleared at this point?
  2. If so, would it be helpful if I revived this?

@Andarist
Copy link
Collaborator Author

Andarist commented Dec 3, 2018

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.

@marvinhagemeister
Copy link
Collaborator

+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.

@ForsakenHarmony
Copy link
Collaborator

Seems like we have a new pr for this

@Andarist Andarist deleted the babel-support branch December 5, 2018 11:55
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.

Doesn't seem to be paying attention to babelrc?