Running scripts without extensions errors if they are on a RO filesystem

[NobbZ]

Expected Behavior

No error when running a script without extension from a read only filesystem.

Actual Behavior

An error when running a script without extension from a read only filesystem.

$ /nix/store/yaw3zrrdjs1y73kgqspk3mj12mc7i4vl-nobbz-flake-updater-0.0.1/bin/update
internal/process/esm_loader.js:74
    internalBinding('errors').triggerUncaughtException(
                              ^

[Error: EROFS: read-only file system, open '/nix/store/yaw3zrrdjs1y73kgqspk3mj12mc7i4vl-nobbz-flake-updater-0.0.1/bin/update.mjs'] {
  errno: -30,
  code: 'EROFS',
  syscall: 'open',
  path: '/nix/store/yaw3zrrdjs1y73kgqspk3mj12mc7i4vl-nobbz-flake-updater-0.0.1/bin/update.mjs'
}

Steps to Reproduce the Problem

1. Create a xz script without extension but with proper shebang on a read-only filesystem
2. run it
3. see the error

Specifications

• Version: 2.0.0
• Platform: linux (NixOS)

[antonmedv]

In order to run it, zx create in same folder file with + .mjs extension. So file system should be writable.

[NobbZ]

Even for FHS linux this is a very hard limitation.

This basically disallows installing ZX scripts (without aa filending) at the system level, eg. in /usr/{,local/}bin, as even though FS isn't RO there, though still not allowed to be written to for most users, and probably result in EACCES.

The file could as well be written to $TMP, $XDG_CACHE_HOME, $XDG_RUNTIME_DIR, depending on what exactly this file is meant to represent.

Currently I'm helping myself by having the *.mjs script somewhere else and an actual executable file that basically is just exec xz /nix/store/…/lib/script.mjs.

[antonmedv]

At first, zx used tmp dir to write mjs file. But from this destination relative imports will not work.

[NobbZ]

Thats in general an understandable limitation. Is there any technical reason for renaming the file at all?

[antonmedv]

Nodejs can't import or require it without extension.

[Dunky13]

It actually can: https://nodejs.org/docs/latest-v14.x/api/esm.html#esm_customizing_esm_specifier_resolution_algorithm

As you can see 14+ can definitely import without extension, albeit with an experimental tag

[NobbZ]

My current use case doesn't involve any require or import at all, yet. Though currently I prefer the manual wrapping I currently do over using an experimental feature of a runtime I am not used to use. Lets just close this issue then as a "wont fix", as it is not fixable. A fix can be done once the mentioned feature has stabilized.