Esm: Load file(s) outside package as ESM

[mAAdhaTTah]

Use case: Building a CLI tool where I'd like the rc file to be ESM.

Because @std/esm's behavior is to scope the loader to just the package, I get unexpected token import when require() / import() 'ing the file. Is there any way to mark that this file should be parsed as ESM?

[jdalton]

Hi @mAAdhaTTah!

There isn't at the moment. However, I'm open to API suggestions or heuristics to enable it. What I want to avoid is accidentally stepping on packages toes in production. So if there's a way to cater to CLIs without stepping on prod deps that would rock 🤘

[mAAdhaTTah]

Perhaps resolvable after we get some hooks (#75)? Assuming that's not happening soon though.

Alternatively, possible to readFile and pass the contents a @std/esm API to compile it ourselves?

[jdalton]

Alternatively, possible to readFile and pass the contents a @std/esm API to compile it ourselves?

That could work! I'll kick it around ⚽️

[mAAdhaTTah]

Cool. Happy to beta test an API if you get something working.

[jdalton]

The more I'm thinking about it.... since we've changed the in-file API to be a loader factory you're opting-in by using the produced loader. That means we could make it so that:

const LoaderFactory = require("@std/esm")
const loaderA = LoaderFactory(module)
const loaderB = LoaderFactory(module, options)

which allow custom options (different than those specified in your package.json) and since you're opting-in by using the produced loader I can remove the package guard per module loaded after.

[mAAdhaTTah]

Yeah, that would work. Is it currently possible to opt-out of the package guard per-module now via package.json? Or that would have to be added as part of this proposal/API?

Also, if this is going to result in API changes, can we reopen the issue?

[bmeck]

If no extensions are used, this seems doable. Otherwise people will need to start guarding against the extensions.

I would suggest adding a package.json if possible and extensions are needed.

[mAAdhaTTah]

Can you clarify "extensions" in the above comment? File extensions or node extensions or...?

[bmeck]

@mAAdhaTTah non-spec behavior. The unlockables

[bahmutov]

So there is no way to load node_modules ES modules at the moment? Like trying to load a lodash-es dependency.

import property from 'lodash-es/property'
// { import baseProperty from './_baseProperty.js';
// SyntaxError: Unexpected token import

The local files are working

[jdalton]

So there is no way to load node_modules ES modules at the moment?

Not without the requesting package opting-in. This issue will enable it through an options param though. It's already committed in the master branch btw. I just have to finish up unit tests to resolve this issue.

[bahmutov]

Cool, thanks @jdalton I will be watching this thread, maybe soon my dream of rolling into smallest possible bundles will come true! Then I will build my library and roll in all dependencies to have 0 production deps.

[Jamesernator]

I couldn't find any packages that are distributed as .mjs to verify, but if lodash-es were distributed as .mjs instead of .js then the above example would just work right? and that the issue is just that you can't configure @std/esm extras for other packages currently.

[jdalton]

Closed by https://github.com/standard-things/esm/commit/4486fdba7067e502dc92dab78552e8c2551394b6, https://github.com/standard-things/esm/commit/7b7e81c58b971307609aa930ec03a349fae44723, https://github.com/standard-things/esm/commit/3eac8b4859d12a108d38811dd20ec3a61cc150df, https://github.com/standard-things/esm/commit/748c8937d880bd116106f797370063e9832b2b8f, https://github.com/standard-things/esm/commit/346dec103a74e24b4cad60e105d771d67d8b1497.

[jdalton]

v0.8.0 is released :tada: