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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide bundled JavaScript files. #140

Closed
6 tasks done
magic-akari opened this issue Aug 8, 2018 · 13 comments
Closed
6 tasks done

Provide bundled JavaScript files. #140

magic-akari opened this issue Aug 8, 2018 · 13 comments

Comments

@magic-akari
Copy link

Description

The browser does not support the bare import.
It is impossible to use lit-element without toolchain (webpack or rollup) now
as lit-element use bare import.
https://github.com/Polymer/lit-element/blob/2433ce376521aa8ab5272aa9c12a49ee74ac8c4e/src/lit-element.ts#L14-L23
or the browser will throw the error:

TypeError: Module specifier does not start with "/", "./", or "../".

It is better to provide different versions of bundled files. Such as UMD, CommonJS and ES Module.
There is an example in Vue project.

Browsers Affected

  • Chrome
  • Firefox
  • Edge
  • Safari 11
  • Safari 10
  • IE 11

Versions

  • lit-element: v0.5.2
  • webcomponents: v2.0.2
@magic-akari
Copy link
Author

There is an example in the article which make it clear.

// Some authors already publish in browser friendly ES6 format.
import Vue from 'https://cdn.jsdelivr.net/npm/[email protected]/dist/vue.esm.browser.js'

// Lodash in ES6 format is published under a different name. When
// using npm, the whole node_modules folder has to be exposed by the
// static web server.
import camelCase from './node_modules/lodash-es/camelCase.js'

// Other libraries are authored in ES6 module format but use bare
// module paths which does not work in browsers. CDNs like Unpkg can
// help by expanding the modules.
import scale from 'https://unpkg.com/[email protected]/index.js?module'

// Sadly there is no module expansion when installed with npm, this
// will NOT work.
import scale from './node_modules/d3-scale/index.js'

@jfbrennan
Copy link

Polymer Team: Embrace the web! Don't make build pipelines and special tools required. If I want or need the additional complexity, I will use preferred tooling, but by all means give developers the easy, ready-to-use option. Stop pretending front-end development needs to look and feel like Java, C#, etc.!!!!

@LarsDenBakker
Copy link
Contributor

If there would be a pre-bundled version available it would not be possible anymore to import lit-html separately. So you could not use lit-html directives, or have other dependencies which also need lit-html.

@jfbrennan
Copy link

jfbrennan commented Feb 19, 2019

I understand for some use cases the extra layer of complexity and overhead required to support importing modules has some incremental benefit.

But this should not be the default (and only) option for LitElement.

It is absolutely possible to offer a lit-element.min.js version that can be dropped into a project (via CDN or local copy) so devs can just start building and shipping:

customElements.define('foo-bar', class extends LitElement {
  ...
});

In fact, I currently get that kind of maximum dev-friendliness from HyperHTMLElement :) But it has issues with slotting :(

Have we forgotten how wonderful it was to work with ready-to-use tools like $, _, axios? Even bigger tools like riot and Vue make this possible. Polymer team should seriously consider making instant use of LitElement possible.

UPDATE: It hit me that it's quite easy to forget something important...

The number of people out there building stuff on the web is HUGE, it's more than any other software environment or platform. Ever!

These people are building static web sites, working within the constraints of a CMS or intranet, maintaining server-side monoliths and SPAs, and pushing the limits with PWAs.

They are young students just getting started, ambitious entrepreneurs, hackers, and professional software engineers (native, back-end, full stack, and front-end specialists).

When you build that mental picture it's easy to see why a solution like LitElement should, by default imo, be distributed in the most accessible way possible. What better way to encourage the adoption of Custom Elements than to give the web LitElement? I'd love to see this project get astronomical adoption like jQuery, but it literally can't happen with the current barriers of entry.

@daKmoR
Copy link
Contributor

daKmoR commented Feb 19, 2019

but it works just fine if you use unpkg?

see this is a demo directly on unpkg.com using unpkg.com to load in its dependencies (LitElement)
https://www.unpkg.com/[email protected]/demo/index.html?module

the same on codepen:
https://codepen.io/daKmoR/pen/darprX

and of course, this also works if you want to import only LitElement 🤗

let me know if you need a more detailed example 🤗

@jfbrennan
Copy link

jfbrennan commented Feb 20, 2019

Setting aside polyfilling (the absolutely wonderful polyfill.io service solves that), the following works with any browser, any project, any skill level:

<body>
  <my-element></my-element>

  <script src="https://a.fast.cdn.com/lit-element-2.0.1.min.js"></script>
  <script>
    customElements.define('my-element', class extends LitElement {
      ...
      render() {
        return this.html`<p>It's lit!</p>`;
      }
    }
  </script>
</body>

Setting aside polyfilling (the absolutely wonderful polyfill.io service solves that), the following does not work with IE11 or less than Edge 16 (and Edge 16 still has no support for dynamic imports), the developer's project is assumed to have a build pipeline and compatible tools for transpiling (welcome to Babhell!) and bundling (made worse by the fact that LitElement is also encouraging use of TypeScript), and assumes mid to advanced skill level (<script> module type, js module concepts in general, import syntax and options, destructuring or importing named exports vs. default export):

<body>
  <my-element></my-element>

  <script  type="module">
    import { html, LitElement } from 'https://unpkg.com/lit-html?module'; // ?module is "very experimental"

    customElements.define('my-element', class extends LitElement {
      ...
      render() {
        return html`<p>It's lit!</p>`;
      }
    }
  </script>
</body>

I'm simply adding my support for a ready-to-use version of LitElement for maximum accessibility and developer enjoyment. Importing the right set of modules using experimental features of unpkg and still needing to set up the necessary build pipeline before production use does not count.

@chase-moskal
Copy link

i think it's a shame that nobody in this thread has yet pointed out guy bedford's amazing solution to this problem

it is with great pleasure i can provide you this link: https://github.com/guybedford/es-module-shims

es-module-shims is an amazing polyfill that allows us to use import maps today!

this allows us to use bare imports! 🕶️

i love it!

cheers! 👋

@amimas
Copy link

amimas commented Jul 4, 2019

I'm new to webcomponent and litelement.

This issue seems close to what I am looking for. If this is not the case, please let me know.

In the guide/doc, there's only info on how to publish my custom element to an npm registry.

https://lit-element.polymer-project.org/guide/publish

My use case is this: I have several sites built with react and some sites built with traditional cms or other framework. I want to build a custom element that can be used by each of those sites. I figured webcomponent/custom element is the best option since different sites are built with different framework and I cannot make too much change to those sites. I want to build my custom element so that it already contains all the necessary dependencies which can be hosted somewhere. Then the consuming sites can just add a <script> tag referring to the custom element source and the element would be immidiately available for use.

I couldn't find info on how to build the custon element using litelement with everything needed bundled up.

Is this what this issue is for?

@chase-moskal
Copy link

@amimas

for your use-case, i have some suggestions, sorted by my favoritism

pika power!!
i'm very glad i can introduce you to this new service called pika cdn

  • ask for any package, and it will instantly give you an all-inclusive bundle!
    https://cdn.pika.dev/lit-element
    it contains lit-html

  • your custom element could import from there directly (or just copy and serve it elsewhere)

    import {LitElement, html, css} from "https://cdn.pika.dev/lit-element"
  • you don't need to have a build step for any of it

alternative: import maps via polyfill
i really love guy bedford's es-module-shims
import maps allows you to control how dependencies are loaded 🕶️

alternative: roll your own bundle
you could use a build step and run your own bundler to create your own bundle

@jsilvermist
Copy link

@chase-moskal Doesn't pika prevent you from using any directives from lit-html though since it imports a different instance/bundle?

@chase-moskal
Copy link

@jsilvermist — ahah, that is an excellent point, and it's true

somebody else raised the same concern in a different issue, see my response there: #724 (comment)

it's a curiosity that lit-element exposes some but not all lit-html exports

basically, this is a use-case where you'd want to use an alternative to pika's magic bundles, so you have more control over the dependencies and their relationships

  • import maps via es-module-shims (plus: avoid any build step)
  • @pika/web as a local package manager (very compelling!)
  • your own bundler like rollup/webpack/etc

@amimas
Copy link

amimas commented Jul 8, 2019

Thanks @chase-moskal for the hints. I will look into those.

@justinfagnani
Copy link
Contributor

I think we capture our ideas for this well in #603, so closing this as a duplicate.

This was referenced Oct 22, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants