5 ms·

>Write your scripts in a file with an .mjs extension in order to use await at the top level. If you prefer the .js extension, wrap your scripts in something lik

>Write your scripts in a file with an .mjs extension in order to use await at the top level. If you prefer the .js extension, wrap your scripts in something like void async function () {...}(). Shebang scripts shouldn't have a file extension in the first place, so requiring one here is a dealbreaker. And having the file extension be used to switch between two different incompatible source formats is really a terrible design.

xboxnolifes 3y ago
> And having the file extension be used to switch between two different incompatible source formats is really a terrible design. Isn't that what all file extensions do? Distinguish between incompatible formats?
- hlandau 3y ago
  I've very rarely seen, say, image viewers which can't handle a JPEG with a .png extension or vice versa, but they're badly designed. Most handle this from the file magic automatically. Keying on extension is definitely an antipattern IMO. I don't see people naming C++ files .c++03, .c++11, .c++17. I don't see people naming Perl files .pl-strict-mode. Yes, it's normal for people to use file extensions, but having programs impose forced usage and semantics to them is a crutch and a sign of bad design. How am I supposed to put a script written using this tool in $PATH? This bad design seems to be a thing in the TS/JS ecosystem now. At least some language ecosystems (Deno? Not sure.) seem to be encouraging people to do 'import ".../Foo.ts"'. Which is abysmal: Firstly these are URLs, yet file extensions are against web principles and good URL design. Secondly they couple a consumer of a module to what language the module was written in and expose this as part of an API, which is terrible design.
  - okamiueru 3y ago
    > How am I supposed to put a script written using this tool in $PATH? Separate file that invokes sh or bash and calls the script file with zx and the path to the mjs file. Should do it. Though I agree with your objection. The requirement for specific extension while also suggesting a shebang, breaks conventions and expectations. From what I can tell from comments made, it's done that way because they prefer it. Which... is a bit silly. But to each their own.
- okamiueru 3y ago
  Extensions are predefined mapping to the executing program. There is no real concept of compatibility there. Useful for media files where you e.g. pick your image-viewer-of-choice, less useful when the script file already has a very strong opinion as to the expected executing binary. Compatibility can be hinted at, but really only determined on the application level. If the script runtime binary then looks at the filename and does something differently based on it, it's likely not correct, and if it is done, it'd better be because of some necessity. The "we prefer it this way" is not a necessity. Plus it breaks conventions and expectations. Enforcing file name extensions at execution, because you want to help an editor figure out how to lint or highlight the file, is also, arguably, letting a specific use case affect something it shouldn't.
iLoveOncall 3y ago
> Shebang scripts shouldn't have Should not have or should not need to have? You can perfectly write a script with a shebang and an extension, stick it in your path, and use it without extension. Therefore, I fail to see how this is a "dealbreaker". Or is it just because "I don't like it!"?
- hlandau 3y ago
  So how am I supposed to put such a script in $PATH? e.g. if I hypothetically want to make a replacement for say 'ls', what am I supposed to do, force people to type 'ls.mjs' rather than 'ls'?
  - guhcampos 3y ago
    ln is your friend
  - iLoveOncall 3y ago
    No, that's my point, every single shell I've ever used would resolve "ls.mjs" if you called "ls" and it's in your path...
pavlov 3y ago
I think this is a Node.js limitation, not a design choice by ZX. You could perhaps use a different JS runtime that doesn't have these admittedly esoteric file extension rules.
- pwdisswordfishc 3y ago
  node --input-type=module This is not a design choice, this is laziness by ZX.

xboxnolifes 3y ago

> And having the file extension be used to switch between two different incompatible source formats is really a terrible design. Isn't that what all file extensions do? Distinguish between incompatible formats?

hlandau 3y ago
I've very rarely seen, say, image viewers which can't handle a JPEG with a .png extension or vice versa, but they're badly designed. Most handle this from the file magic automatically. Keying on extension is definitely an antipattern IMO. I don't see people naming C++ files .c++03, .c++11, .c++17. I don't see people naming Perl files .pl-strict-mode. Yes, it's normal for people to use file extensions, but having programs impose forced usage and semantics to them is a crutch and a sign of bad design. How am I supposed to put a script written using this tool in $PATH? This bad design seems to be a thing in the TS/JS ecosystem now. At least some language ecosystems (Deno? Not sure.) seem to be encouraging people to do 'import ".../Foo.ts"'. Which is abysmal: Firstly these are URLs, yet file extensions are against web principles and good URL design. Secondly they couple a consumer of a module to what language the module was written in and expose this as part of an API, which is terrible design.
- okamiueru 3y ago
  > How am I supposed to put a script written using this tool in $PATH? Separate file that invokes sh or bash and calls the script file with zx and the path to the mjs file. Should do it. Though I agree with your objection. The requirement for specific extension while also suggesting a shebang, breaks conventions and expectations. From what I can tell from comments made, it's done that way because they prefer it. Which... is a bit silly. But to each their own.
okamiueru 3y ago
Extensions are predefined mapping to the executing program. There is no real concept of compatibility there. Useful for media files where you e.g. pick your image-viewer-of-choice, less useful when the script file already has a very strong opinion as to the expected executing binary. Compatibility can be hinted at, but really only determined on the application level. If the script runtime binary then looks at the filename and does something differently based on it, it's likely not correct, and if it is done, it'd better be because of some necessity. The "we prefer it this way" is not a necessity. Plus it breaks conventions and expectations. Enforcing file name extensions at execution, because you want to help an editor figure out how to lint or highlight the file, is also, arguably, letting a specific use case affect something it shouldn't.

iLoveOncall 3y ago

> Shebang scripts shouldn't have Should not have or should not need to have? You can perfectly write a script with a shebang and an extension, stick it in your path, and use it without extension. Therefore, I fail to see how this is a "dealbreaker". Or is it just because "I don't like it!"?

hlandau 3y ago
So how am I supposed to put such a script in $PATH? e.g. if I hypothetically want to make a replacement for say 'ls', what am I supposed to do, force people to type 'ls.mjs' rather than 'ls'?
- guhcampos 3y ago
  ln is your friend
- iLoveOncall 3y ago
  No, that's my point, every single shell I've ever used would resolve "ls.mjs" if you called "ls" and it's in your path...

pavlov 3y ago

I think this is a Node.js limitation, not a design choice by ZX. You could perhaps use a different JS runtime that doesn't have these admittedly esoteric file extension rules.

pwdisswordfishc 3y ago
node --input-type=module This is not a design choice, this is laziness by ZX.