ESM Support for Nx Plugins

[AgentEnder]

• [x] I'd be willing to implement this feature (contributing guide)

Description

Nx plugins must be written in CJS

Motivation

ESM is the future, and the way things are going this will be necessary at some point.

Implementation path

Places that import nx plugins, must dynamically import them

• [ ] loadNxPlugins
• [ ] loadNxPlugin
• [ ] readGenerator
• [ ] readExecutor

This is difficult on our side, since readGenerator / readExecutor are on the Workspaces class, a public devkit API. Additionally, project inference capabilities make use of loadNxPlugins. This stuff gets hit in getProjects(tree: Tree), readProjectConfiguration(tree: Tree) etc. Those are major public API points in terms of internal use and community plugin use, let alone workspace-generators or local plugins within an organization.

ALL of these APIs will need to go async only, representing a major breaking change.

[thomasskk]

Any idea about when we can expect this feature ? Like 1/3 months or more ?

[AgentEnder]

There's not a rough timeline yet, and as noted it will be a pretty major breaking change. V16 should be soon (soon enough that there won't be any progress on this in all likelihood), and we do a major approximately twice a year.

Based on that info, I would say 6 months -> 1 year.

[passbyval]

For anyone else experiencing issues with ESM imports, I created this small util as a workaround for now: https://gist.github.com/passbyval/b85f79381816c197c5c651b7c0b00d5e

[JulioC]

I've been using the runtime evaluated import solution, as seen in the official plugins.

It would be nice if either this or passbyval's solution would be offered as a utility from the nx/devkit.

---

Now, we do need a definitive solution for it, since many plugins are migrating to ESM format in the past months, and it's really annoying to do that workaround for everything...

@AgentEnder can we expect this fix to come in the next major?

Edit: another reason for the fix is that any workaround will be a Promise, which requires even more changes in affected plugins.

[RichiCoder1]

Just ran into the dynamic import issue. In theory packages don't need to be migrated to ESM as modern typescript supports not downcompiling import statements which would allow CJS to at least import ESM modules without hacks.

That said, full ESM support would be amazing.

I also ran into a typescript issue (which may have been my fault?) where typescript was complaining that typeof import('package') wasn't supported, so I adjusted the above hack to look like this:

  const { execa } = await (Function('return import("execa")')() as Promise<
    // @ts-expect-error
    typeof import('execa')
  >);

[Bielik20]

Hello @AgentEnder do you have any updates on that? The last estimate was 6 months -> 1 year and that was almost exactly a year ago. I would only like to know what are the plans, and what can we expect. Thank you in advance.

[yusijs]

I would expect native support for esm landing in node to help quite a bit here. However, that is just experimental, so wouldn't expect it to land very quickly.

https://twitter.com/JoyeeCheung/status/1769670125849104863

[ryanolsonx]

Any update on this? This is high priority for my team.

[austinbiggs]

I'm also looking for guidance from the Nx team. This issue is a year and a half old; what can users expect to see as a resolution? 🙂

[nidomiro]

The workaround wee settled on is, to transpile the needed packages from esm to cjs with esbuild in the postinstall-step. It is not the best approach, but at least we can update packages again.

Tbh. I don't think this issue will be addressed anytime soon; even tough it is an improtant one.