Release compiled / dist version
kmalakoff opened this issue · comments
Awesome library. Just what I was looking for!
Running babel inside node_modules and having library users install transform-es2015-modules-umd should be optional (remove .babelrc from distributed module)
Just noticed that there is a compiled version...it includes the word class so maybe it is a build pipeline bug:
In mixwith.js:
class MixinBuilder {
constructor(superclass) {
this.superclass = superclass;
}
I compile ES2015 modules to UMD because no native environment supports modules, but plenty of them support classes. If you're targeting a VM that doesn't support classes you can compile them out.
Otherwise I'm not sure where we should draw the line in terms of JS features to avoid - it really depends on the users of the library, not the library itself.
You should aim to distribute a version that works with common build pipelines without the need to install babel plugins (BTW: the plugin you included in your .babelrc conflicted with other babel plugins so I ended up giving up on this library).
To draw the line, iIf you want to distribute a version with classes, can you put an esnext field in your package.json? I think it would be best to not include the babel plugins that you used to transpile the library and provide a packaged version for ES5 for maximum adoptability. I typically use the webpack UMD target since it is a well trodden path.
I'm not exactly a Babel expert, so does the .babelrc enforce that plugin be installed into dependent packages using Babel? That would indeed be inconvenient, and I can fix that by including the Babel config directly in the gulpfile I guess. I didn't think this setup was requiring users to install a plugin.
Anyway, my intention was to distribute a version that could at least be loaded without any compilation in the latest Node, Chrome, FF, Edge and WebKit for development, and then compiled to whatever the intended production target is. I figured that since mixwith.js is really very focused on classes, users will almost certainly be working with native class support or a compiler already.
I'll look into a better compiler config and dist setup in the next few days as I have time.
Yeah, I've never seen a .babelrc file be released along with a library before, but it did get picked up (in addition to my config) and made me have to install the plugins for this library. If you could embed the config in the gulpfile, that would help.
I see your target and predicament. I'd probably target ES5 in any library released even if this is a class-related library since prototypical inheritance should still be compatible. I think using classes directly would fit more in an esnext entry, but I haven't used this entry so I'm not sure how widely supported it is by build tools, but I believe that's what it is for.
When you release an update, I'd be happy to try it out and provide feedback.
+1
This is a blocking bug for me too, I'm using rollup with babel plugin to transpile and bundle my source. @justinfagnani basically babel will look for a .babelrc in the folder of the file it's currently processing, and traverse up if it can't find one. See Lookup behavior. I think programatically setting the babel preset in your gulpfile would resolve it?
The other option might be to expose the ES2015 version in package.json using jsnext:main. That would also allow people to use tree-shaking if they're using something like rollup. Though I'm not sure how common (if at all) jsnext is outside of rollup land.
Edit: Made a PR to remove the .babelrc, not sure if that's the solution you're after but I needed to do it for my setup anyway so thought I'd add a PR incase it was.
To come back and clarify why I closed this, it's not possible for ES5-style classes to extend ES6 classes, in particular super() just isn't emulatable at all. If I distributed this as compiled JS, it wouldn't be usable with uncompiled ES6. I think it's better if applications use and compile standard ES6 as needed.