Support for direct-to-browser ESM
From the docs, it looks like the project installs in the browser's global namespace.
Are there any plans to distribute an ES module directly to browsers (without Node.js) that can be imported with an ES6 import declaration?
For instance:
<!DOCTYPE html>
<html lang="en">
<head>
<link rel="modulepreload" href="https://path/to/HumanizeDuration.js">
<script type="module">
import humanizeDuration from 'https://path/to/HumanizeDuration.js';
console.log(humanizeDuration(97320000));
</script>
</head>
</html>
For reference, Luxon is distributed in that form, with both a full and a minified version available.
I'd like to add ES module support to this package, but I'm not sure how I want to do that yet.
I've added it to my to-do list. I will probably not get to this soon, apologies.
but I'm not sure how I want to do that yet.
Could I make PR for it?
Yes, but please let me know how you plan to do this beforehand. There are a lot of different ways to accomplish this and I don't want you to have to do a bunch of unnecessary work.
Yes, but please let me know how you plan to do this beforehand. There are a lot of different ways to accomplish this and I don't want you to have to do a bunch of unnecessary work.
Okay, sorry for the late response, I had to finish a personal project 😅
I would fork this repo and do the following things:
- make
d.tsfile for all type declarations (all@typedef->interfaceandtype) - use the common ES2016 or ES2020 syntax (import instead of require) - tell what I should use: ES2016 or ES2020 or something else
- create a default export for the default function - which I also want to deconstruct a bit, if possible
Thanks for writing this out, because it helps me figure out what's needed.
I think my requirements are:
- Add ES Module compatibility.
- Maintain ECMAScript 3 compatibility. This module is still compatible with very old browsers, and I'd like to keep it that way.
- Maintain CommonJS support.
- Maintain AMD support (see the code).
- Maintain
windowsupport. It should still be possible to use this module with CommonJS, and it should still be possible to use<script src="humanize-duration.js"></script>. Importantly, it should still be possible to copyhumanize-duration.jsand use it in a<script>tag with no changes. - Do not change TypeScript support as part of this work. It's possible we want to add that, but that's unrelated to ESM.
I think that means shipping two files in the npm package: humanize-duration.cjs and humanize-duration.mjs (or something like that). The latter would be auto-generated and put in the .gitignore file, and only included at build time.
Is that something you could help with?
Please also split the single 50kB script into multiple files so the Browser only imports the languages that it needs.
@sbaechler I'm currently not working on that, but thanks for bringing this back to my attention 😂
I will see what I can do.
No worries, I am not using the library either 😂. The calculation is using constant values and does not account for different lengths in months or daylight saving time.
Date-fns has a function that converts Durations in human readable form given a start date. I think the new Javascript Temporal object also supports this natively.
@sbaechler oh, interesting 👀