Explicit inclusion of magic number in spec

[rvagg]

Can we have a commitment to include a magic number in this new format? A lot of the pain that Node is experiencing around supporting ES Modules is the inability to determine whether a file is ESM or CJS based on the ambiguities that exist in the syntax and the lack of some kind of pragma. The controversy around .mjs vs .js exists almost entirely due to this ambiguity. Since Node can't use mime-types like the browser, a leading pragma or magic number in these new file formats that VMs can load would provide much more optionality than having to simply rely on file extension.

[Yoric]

It's not written down in spec yet, but for the moment, there is a magic number "BINJS\0" (which should be upgraded to "BINJS\1" once the container format stabilizes).

[kannanvijayan-zz]

Committing to a magic number in the format should be non-controversial. It's a binary format, and magic bytes are basically standard practice. If anything, the decision to NOT include a magic would require justification instead of the other way around.

If we wanted to be clever, the magic could be "#!/usr/bin/env binast\n<VERSION>\n...". Would allow seamless hooking of binast files into shell loaders for most environments.

On Wed, Oct 25, 2017 at 3:24 AM, David Teller [email protected] wrote:

It's not written down in spec yet, but for the moment, there is a magic number BINJS\0 (which should be upgraded to BINJS\1 once the container format stabilizes).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/syg/ecmascript-binary-ast/issues/20#issuecomment-339239199, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0I2g_TGRjAH6MV9UKQ4OmW-rI_4FE9ks5svuIrgaJpZM4QFFa9 .

[bmeck]

It should be noted that even with a magic number; I would hope this uses a different file extension / MIME