Tracking upstream PR

[MylesBorins]

Opened in nodejs/node#26745

Will comment if anything needs to be done on our side

[MylesBorins]

@devsnek has objected to including -m in the upstream PR

I've removed it in nodejs/node@a3510b1, anyone have concerns with this?

edit:

discussion in nodejs/modules#295

[MylesBorins]

another point came regarding the name of the flag --type being too generic. I've renamed it --entry-type. There is also the question regarding if it should be scope to entry point or be an alias to override package.type... basically the exact conversation from the last meeting

Latest comment nodejs/node#26745 (comment)
Implementation nodejs/node@59a4ef8

edit

discussion in: nodejs/modules#296

[SMotaal]

@devsnek I think -m was to align it with other js runtimes out in the eco-system

One example

~/P/@/node ❯❯❯ jsc -h                                               ⏎
Usage: jsc [options] [files] [-- arguments]
  -d         Dumps bytecode (debug builds only)
  -e         Evaluate argument as script code
  -f         Specifies a source file (deprecated)
  -h|--help  Prints this help message
  -i         Enables interactive mode (default if no files are specified)
  -m         Execute as a module
  -s         Installs signal handlers that exit on a crash (Unix platforms only)
  -p <file>  Outputs profiling data to a file
  -x         Output exit code before terminating

  --sample                   Collects and outputs sampling profiler data
  --test262-async            Check that some script calls the print function with the string 'Test262:AsyncTestComplete'
  --strict-file=<file>       Parse the given file as if it were in strict mode (this option may be passed more than once)
  --module-file=<file>       Parse and evaluate the given file as module (this option may be passed more than once)
  --exception=<name>         Check the last script exits with an uncaught exception with the specified name
  --watchdog-exception-ok    Uncaught watchdog exceptions exit with success
  --dumpException            Dump uncaught exception text
  --options                  Dumps all JSC VM options and exits
  --dumpOptions              Dumps all non-default JSC VM options before continuing
  --<jsc VM option>=<value>  Sets the specified JSC VM option

Can you reconsider things from this perspective?

I think @WebReflection gave a more informed insights on this here:

About -m

Even if this shortcut is limited to the module type only, it's pretty consistent with the rest of the CLI based ecosystem (SpiderMonkey / JSC) so, if there will be any shortcut, I think -m should be considered as special case over alternatives such as -t module or -et module

[SMotaal]

Worth noting that -m appears to be catching on elsewhere as can be inferred from @joyeecheung's comment

Why? Aren't -m and the package.json field enough for most use cases? Shortcuts are exceptions as they are not even really names, you'll have to look at the docs anyway.

[devsnek]

@SMotaal debug shells don't really have any design process (and they exist for debugging, not real world usage), I wouldn't use behaviour from them as any sort of indicator for what we should do.

[WebReflection]

@devsnek I use those shells from time to time, and it's handy to have a single entry point that works almost seamlessly for all the use cases.

Both jsc and js60 are quite aligned in their flags implementation, all m, f, e, or i are there, and let's remember all these shells have a way to read files and use RegExp, so as tools these could be handy too.

I'm not saying it's a common use case to spin js60 on Linux, or jsc on macOS, but like you told me in the other thread, let's not state "not real world usage" when that's not necessarily the case.

That being said, beside being -m eventually aligned with what might have been discussed elsewhere, as in mozjs/jsXX or jsc, -m it's super handy for any dev that need ESM right away while performing any shell session.