ESM support

[Gozala]

Hi @Treora

I would like to use without build steps in the environment that has ESM support. There are few things that prevent it right now:

1. ES modules require .js file extension to work. Given the source code is authored in ESM it should not be fairly simple to update all relative imports so they have file extension.
2. External dependencies. Sadly there is no simple solution for that. But I would like to suggest following workaround:
   • Replace improts like import documentOuterHTML from 'document-outerhtml' with something like import documentOuterHTML from '../../modules/document-outerhtml/index.js'
   • Create simple files like modules/document-outerhtml/index.js that just do module.exports = require('document-outerhtml')

No 2 is far from ideal but it would make it fairly easy for anyone to remap that to whatever they need. Although it does incur extra maintenance burden here.

I'll probably do one or possibly both of these things as I'd like to make use of this code & will be happy to upstream changes to either or both if that sounds reasonable.

[Gozala]

I made a change No 1 as proposed above https://github.com/Gozala/freeze-dry/commit/3b80e29428df34d8c858a5e76a35e994d669d21e

[Gozala]

And here's the change I made for No 2 as per proposal above https://github.com/Gozala/freeze-dry/commit/7ce37b32dd84b5dde990691801a88417a3a31a77

[Treora]

No 1 seems a no-brainer, fine with me.

For No 2 I wonder if that is really the best we can do. Could we instead invent another way to run without build step, by running some build step as part of the publishing process? I have not kept up with the javascript/npm ecosystem in the last months, so I might be a dinosaur by now. ;)

[Gozala]

No 1 seems a no-brainer, fine with me.

I’ll submit pull containing just those changes (although next week is Moz All Hands so it will be a little while)

[Gozala]

For No 2 I wonder if that is really the best we can do. Could we instead invent another way to run without build step, by running some build step as part of the publishing process?

Maybe, but I didn’t really came up with a solution that would work.

This is somewhat promising, but not sure it will be available in browsers in my lifetime do..

I have not kept up with the javascript/npm ecosystem in the last months, so I might be a dinosaur by now. ;)

Still a mess & resistance to ES modules from node is just sad.

[Gozala]

Maybe some adapted version of this could be used during builds but to rewrite urls not to unpkg but to a relative url that assumes deps are at the same level as package itself

https://www.npmjs.com/package/babel-plugin-unpkg

[Gozala]

I would like to mention few things I have discovered.

1. Deno that is another JS / TS server runtime from Ryan Dahl author of node. It an attempt to fix major regrets in of node. It uses ES modules and gets rid of packages below is relevant quote from the docs that absolutely resonates with me:

   It seems unwieldy to import URLs everywhere. What if one of the URLs links to a subtly different version of a library? Isn't it error prone to maintain URLs everywhere in a large project? The solution is to import and re-export your external libraries in a central package.ts file (which serves the same purpose as Node's package.json file). For example, let's say you were using the above testing library across a large project. Rather than importing "https://deno.land/x/testing/testing.ts" everywhere, you could create a package.ts file the exports the third-party code:

   export { test, assertEqual } from "https://deno.land/x/testing/testing.ts";

   And throughout project one can import from the package.ts and avoid having many references to the same URL:

   import { test, assertEqual } from "./package.ts";

   This design circumvents a plethora of complexity spawned by package management software, centralized code repositories, and superfluous file formats.

2. I have also started using webrun for node projects that also attempts to replace node modules / packages with ES modules while leveraging node itself. Not sure if this if it would be a good idea for freeze-dry to use this but I thought I'd mention it here never the less.

[Gozala]

I would like to endorse approach inspired by deno. That is to create package.js in the project root and export all external dependencies from there. It would also make it fairly easy maintain a fork that just remaps dependencies differently.

[Treora]

@Gozala I made a stab at this in #39. Is that what you had in mind? Suggestions welcome.

[Gozala]

Yes thank you! That’s perfect

[Treora]

Merged. It seems to make the code a little more confusing, but let's go with this for now. If neater approaches get traction I'm open for adopting one.

I assume we can close this issue, having addressed both original points.