-
Notifications
You must be signed in to change notification settings - Fork 914
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
why lit-html is not transpiled to es5 in npm? #516
Comments
Short answer is: this is needed to use native ES modules in browser (with the small transform which consists of resolving package names to paths). Same applies to lit-element and most of web components around Polymer community (as they use native ES2015 classes and transpiling affects them by imposing the need for additional shim). Example babel-loader config to work with lit-html can be found here: https://github.com/web-padawan/lit-components/blob/f4f17f6267cf440dd8abdb7f4794a66cdc51330b/utils/webpack.common.js#L6 @justinfagnani I do think this should be clearly documented and explained with code examples. Not everyone will use Polymer CLI, most of people will prefer Webpack etc. |
I don't use Polymer CLI or Webpack. I ran into this went trying to use lit-html/lit-element with Meteor. Luckly MDG was able to come up with a solution using symlinks. |
@maciejw Actually, you can set up your webpack to compile several packages from Regarding the need of compilation to ES5-compatible source. I would strongly disagree with the comment you provided. We've entered the era when all evergreen browsers supports ES2015 standard, so it becomes unecessary for the users of Chrome, Firefox or Edge receive unnecessary bytes of code that was transpiled just because some old browsers don't support some features. And this situation is completely hopeless for someone who don't want to support IE11 and its older versions. There is no compiler to get ES5 compiled back to ES2015 and almost all libraries in npm goes compiled. Why should my users use Babel FSM while their browsers supports I think npm libraries should be written and distributed with ES2015 code. If any site has a need to support old browsers it can compile them by itself. Just small changes in webpack configuration. It can even create a special build for old browsers and distribute it identifying by User Agent. It becomes more important for a library like There is a great post from Henry Zhu, Babel maintainer, about moving to "post-ES5" ecosystem. I completely agree with his opinion. |
thanks for followup on this, I know that our ecosystem is in constant flux, its is even more important to be explicit about stuff you said, so documenting it is good idea, I hope this thread will help someone. Henry Zhu expresses same concerns that I had in mind... but also shines new light on few things, good post. I know that its possible to setup webpack to transpile I've heard cool thing that Scott Hanselman once said about consuming dotnet, when MS was working on http://dot.net core. He said something along those lines, it should be easy to consume, I want to have nice domain, users will download run-time from with easy setup and I want to type JS environment has opposite approach I think :) its not a complain its and observation :) |
We distribute standard JS modules because we need to:
Standard modules are the only format that allows all three. The only requirement on applications is that if they're using a non-standard module format, that they compile the lit-html modules to that format. With regard to other ES5 features, we distribute ES2017 because we can't know anything about the target environment, including class, arrow function, or const/let support. Only the application developers know those constraints, so only they can configure the compiler correctly. We only use standard ES2017, so you don't need to configure your compiler with any exotic plugins. While we do write lit-html in TypeScript, that's compiled to standard ES2017 before publishing. To go from ES2017 to whatever your target is you can use Babel, TypeScript, Closure, Bublé, or any other standards-compliant JS compiler. |
Hi, First, thanks for your work! At this time (I'm a newbie, sorry if this comment doesn't make any sense), I try to consume However, I'm not able to consume Am I missing something? |
@charnould you don't really need Webpack for Node. Adding @babel/register into your code should do the job, and it's just 1 line of code. It can be also used with tools like |
Thanks. I can now use
|
@charnould lit-html uses browser APIs that aren't available in Node. It's not going to work unless you load it in a browser emulator like jsdom. |
@justinfagnani after babelization of the ES2017 result of Moreover, is it going to work as expected? Since |
We use lit html compiled to es5. Performance impact is the same as any other library, you end up shipping more code. Dom rendering itself is the same though. Async compiles just fine, otherwise it wouldnt be a babel option. :) |
@rbosneag we recently shipped a set of global navigation elements built on lit-html (& lit-element) with browser support down to IE11—no problem at all re:the transpiration down to es5. |
Understood! |
@emilio-martinez can you share your setup, I've spent hours poking ideas into webpack, typescript and babel configs but I have no solution yet. Here is my fork of typescript babel webpack where I try to adopt lit-element: https://gist.github.com/tiberiucorbu/2c3cdc60b1941939e288ae11ffeaed0e |
@tiberiucorbu I believe it mostly came down to adding an entry in the Webpack rules array to let Webpack know to handle these packages. In our case we passed them to ts-loader, but I'm sure the same could be done with babel. The entry we added looks like the below.
|
Thanks @emilio-martinez, I managed to nail it down with two steps : in webpack I bundle ts to esnext that produces a bundle that contains all the goodies : "async, class extends..." and then in a post step, using babel I'm recompiling the esnext bundle to an |
Using browserify and no babel or other compile tooling in my project I ended up wanting this, so I published a precompiled version as https://github.com/wesleytodd/es5-lit-html I would be happy to hand this over to the polymer team if they want it. If not, I will try to keep track of when releases are made here and publish the corresponding versions asap. Edit: should have added, other than this part it is working great! Got up and running today with hardly any issues. Great work team! |
Thanks for doing that. I think the general agreement was to leave build
preferences up to the user. But it's nice to know that a pre-transpiled
version is available.
|
I don't think this is a good idea. Interop between the built and unbuilt versions will not work correctly. Edit to add: And I want to point out again that shipping unnecessarily compiled code to modern browsers negatively impacts perf and code size. You'll be disadvantaging most of your users. We've seen a 25% difference in app size between ES5 and ES2017. Differential serving or using |
I understand your reasoning for not shipping it. That said, I am sure many users don't want to have to make changes to their build for one lib in their app. Since my build tool chain is commonjs, and productivity is my primary concern (not perf), it made sense for me. I am sure it makes sense for others, and I will leave it up to them to make the same decision. Your comment alludes to specific compat issues. Are there specific things you know of that will break? It seems to work for me in my basic usage so far. |
Hello, Currently I'm working on Angular project where I want to use lit custom elements, that project is using angular-cli and I will need to add special additional step to translate lit, hack lib mapping, what is not simple especially with monorepo/lerna project :( Delivered es5 code will solve all my problems :) |
@majo44, I believe it is an issue of the Angular CLI, not the |
As I said, I understand, I'm sad too about %, but revolution will not happens from day to day, but slowly step by step, tool by tool, lib by lib, and to speed up this process we can't say "hey we have to replace everything today". I'm not working with Ng because I want, but because my managers and colleagues do not know and do not trust in alternatives, convince them to web components took for me a months. If I will told them "I have super power lib, but we have to change all code to es6" no one will allow me to even look at that lib, also even If I will say "but your dev process have to be changed" it will not simplify. But if in some time, my all libs, my whole workflow will be ready for simple switch to es6, I will do that, and there will be not any defiance. |
Remember that you do not need to move your entire project to es6 to use es6-based dependencies. You can add one file that imports all your es6 dependencies, run that file through Rollup, and then you have a single es5 file with all your dependencies that you can use in your project. |
@ruphin is exactly right. The only require is that if your app needs to compile to ES5 that you compile your ES6 dependencies to ES5. This can be done in Webpack and Rollup configs relatively easily. For Angular CLI users there's an article on using custom Webpack configs here: https://alligator.io/angular/custom-webpack-config/ |
I love our community, and consistency in our ecosystem. @justinfagnani even in your company (God bless Google) you are not consistent (APF?WTF?). So what I can expect :( I know that I'm able, I know how to do that, but I do not think that this is good to do that in this way. If you do not want to do that for me (or other people), please do that for mother earth:
~23h of compilation time required weekly, just because you do not do that once per release :) Best regards. Please forget my request. |
@majo44 we have pretty much nothing to do with the Angular project. They've chose to make their own packaging format, but that's not something we would do. I consider it too complex for our team and goals. I've stated in this thread why it's a technical problem if we publish more than one version of our libraries. We don't want to enable the bugs that will result from that. |
I am sorry if I triggered this conversation to go further. I think it sounds like a good decision for the Polymer team to not publish a transpiled version. Their responsibility should be focused on what is best for the library. If they think supporting two formats is counter to that, fine. This is why OSS is great, for those of you who (like me) want a transpiled version, it is as simple as publishing it. I did it for you. Let's let them get back to all the other more worthy things they can be doing :) |
The problem with a transpiled es5 version is that it requires on the runtime the adapter and is about ~30% bigger that the es6 bundle, so just because of IE11 our clients that use a modern browser have to download and process more JS than required. I think we need both bundles and the tooling that enables that. |
You can reach that by using webpack-babel-multi-target-plugin. It does exactly what you ask for: ES module and ES5 bundles. Check the polymer3-webpack-starter as an example of using that plugin. AFAIK, in the upcoming Angular 8.0 there will be a similar tool baked into CLI. |
Thanks for sharing @web-padawan |
This babel config not work for me , and I google a lot but didn't find a solution. |
Can you clarify something?
when someone publishes package to npm with module and main properties, the only difference should be es6 module format, packages should be both es5 compliant.
webpack/webpack#1979 (comment)
in your case, you publish modules not transpiled to es5, you are es2017 compatible.
can you clarify, whet is proper way of consuming this package, to use it with webpack, when webpack and babel for that matter will not transpile node_module files from es* to es5.
you can program your library in whatever you like, some exotic babel plugins with experimental syntax, when you publish it to npm, you force consumer of this library to know what those plugins are and configure transpilation locally, this is quite ridicules assumption on your part if true, I think :) so I'm asking :)
The text was updated successfully, but these errors were encountered: