HumanizeDuration.js icon indicating copy to clipboard operation
HumanizeDuration.js copied to clipboard

Support for direct-to-browser ESM

Open MagnusOxlund opened this issue 1 year ago • 10 comments

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>

MagnusOxlund avatar Sep 27 '24 06:09 MagnusOxlund

For reference, Luxon is distributed in that form, with both a full and a minified version available.

MagnusOxlund avatar Sep 28 '24 05:09 MagnusOxlund

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.

EvanHahn avatar Sep 28 '24 15:09 EvanHahn

but I'm not sure how I want to do that yet.

Could I make PR for it?

The-LukeZ avatar Oct 14 '24 12:10 The-LukeZ

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.

EvanHahn avatar Oct 14 '24 13:10 EvanHahn

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.ts file for all type declarations (all @typedef -> interface and type)
  • 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

The-LukeZ avatar Nov 03 '24 17:11 The-LukeZ

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 window support. 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 copy humanize-duration.js and 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?

EvanHahn avatar Nov 03 '24 21:11 EvanHahn

Please also split the single 50kB script into multiple files so the Browser only imports the languages that it needs.

sbaechler avatar Sep 12 '25 15:09 sbaechler

@sbaechler I'm currently not working on that, but thanks for bringing this back to my attention 😂

I will see what I can do.

The-LukeZ avatar Sep 15 '25 08:09 The-LukeZ

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 avatar Sep 15 '25 10:09 sbaechler

@sbaechler oh, interesting 👀

The-LukeZ avatar Sep 16 '25 05:09 The-LukeZ