WebReflection / hyperHTML-Element

An extensible class to define hyperHTML based Custom Elements.
ISC License
202 stars 25 forks source link

ES6 Module #10

Closed ghost closed 6 years ago

ghost commented 7 years ago

Please export this as an ES6 module with an .mjs file the same way you did with hyperHTML.

WebReflection commented 7 years ago

this file depends on hyperHTML ... how am I supposed to import that? from where?

asapach commented 7 years ago

If you use a bundler like webpack, rollup, systemjs-builder, etc. you can just do import {bind} from 'hyperhtml' and it will resolve it from package.json. There's a proposal to use module property to reference ESM.

I don't think browsers natively support anything other than relative or absolute URIs, so it's more problematic.

WebReflection commented 7 years ago

the module doesn't resolve much here. He asked to export mjs like in hyperHTML and you can already use mjs in hyperHTML. Here the dependency is arbitrary and CJS has no isues with that, neither browserify etc. With ES2015 modules though, where do I grab hyperHTML? I can just export the class and let developers pollute the global scope requiring hyperHTML a part but that would not play nice.

I can import hyperHTML from unpkg right away but that wouldn't play nice.

I can bundle HyperHTMLElement class with hyperHTML too but that could be redundant.

Accordingly, and I am asking to @chrismbeckett , how am I supposed to bring in hyperHTML here?

One way could be by exporting a function that accepts an hyperHTML parameter so that you

import parser from 'hyperhtml';
import hyperComponent from 'hyperhtml-element';
const HyperHTMLElement = hyperComponent(parser);

dunno ... really :man_shrugging:

asapach commented 7 years ago

Instead of dependency on global hyperHTML, you could replace hyperHTML.bind() with:

import {bind} from 'hyperhtml'
...
... this.html = bind(
...

If you add module: 'min.mjs' to hyperhtml's package.json, bundlers should be able to resolve 'hyperhtml' import. This won't work for browsers, however. One caveat, though: module should be an ES module, but otherwise should use ES5/ES3 syntax to allow bundlers skip transpilation.

asapach commented 7 years ago

Here's a random example: https://unpkg.com/react-router@4.2.0/es/StaticRouter.js

ghost commented 7 years ago

How did you publish a CSS module on Bower that required referencing an image published in another package? How did Polymer components bundled as HTML imports reference external dependencies? They assume that people are using the package manager the project is using, and assume relative paths to other modules. I know this kind of sucks, but browsers have chosen to implement ES6 modules and only support absolute or relative paths. I know we have all become used to smart module loaders that auto-resolve things for us.

Personally, I preferred the approach that JSPM was using to have an ES6 module loader in the browser that was configurable so module imports could be automatically resolved like we expect with Node without burdening library authors with this crap. But that doesn't matter, this is how it is.

Polymer is moving from Bower to NPM, and for the foreseeable future, relative paths for imports of web libraries in NPM is going to be required with tools such as Rollup and WebPack being able to rewrite imports. I don't have all the answers, I am trying to figure this out myself now as well. I know this - I have over 40 web components written in Polymer that I am starting to migrate to HyperHTML, ES6 modules and NPM, and I have dependencies between them. I am planning to use relative paths assuming that other modules will be in adjacent folders.

BTW - Chrome and Firefox won't actually load .mjs files. Despite having read numerous blog posts that browsers shouldn't care about the file extension (just type=module on the script link) - they do. I had to rename your HyperHtml min.mjs to min.js to get it to load in both Chrome and Firefox behind the ES6 modules flag.

WebReflection commented 7 years ago

BTW - Chrome and Firefox won't actually load .mjs files.

Yes, they do, but the file has to be served as content-type application/javascript

Here an example: https://webreflection.github.io/hyperHTML/test/mjs.html

WebReflection commented 7 years ago

@chrismbeckett I am curious to see where this proposal goes: https://github.com/whatwg/html/issues/3056

that might be the key to solve any issue in here, so that I can simply import bind from "hyperhtml"; and let consumers chose where that comes from, no matter which bundler they are using.

WebReflection commented 6 years ago

current status:

aaronshaf commented 6 years ago

Would be nice to have a single minified file to import as an ES6 module. Or maybe there is already a solution for that? And I missed it.

NoBuildStep

synaptiko commented 5 years ago

Today I encountered the same problem, I've created this: https://github.com/synaptiko/hyperhtml-element-esm-bundle

You can then import HyperHTMLElement as a default export or any hyperhtml's export as named export (see https://github.com/synaptiko/hyperhtml-element-esm-bundle/blob/master/index.js). Those two are bundled in one file, either as esm.js or as min.js.