007: --entry-extension CLI flag proposal by bmeck · Pull Request #62 · nodejs/node-eps

bmeck · 2017-08-09T14:32:19Z

No description provided.

bmeck · 2017-08-09T15:25:59Z

@rauschma: bikeshed for --input-extension instead

ljharb

What happens with node --entry-extension=js app.js or node --entry-extension=mjs app.js?

I would expect either an exception when there's a mismatch, or, that the entry-extension would silently override the file extension.

bmeck · 2017-08-09T16:26:24Z

Mixing anything that is not an opaque text stream such as a filename should error since it doesn't make sense.

matthewp · 2017-08-09T17:00:28Z

In @ljharb's case I would want/expect the entry-extension to silently override the file extension. If it throws, then

node --entry-extension=mjs app.js

and

node --entry-extension=mjs < app.js

Would do different things, and why should they?

matthewp · 2017-08-09T17:01:13Z

Ah, I missed @bmeck's reasoning, nevermind. That's fine I think.

rauschma · 2017-08-09T17:03:08Z

@bmeck: I mostly agree, but executing a .js file as an ES module may be a use case.

bmeck · 2017-08-09T17:04:14Z

@rauschma pipe it in over STDIN

rauschma · 2017-08-09T17:05:30Z

@bmeck As that is the only use case I can think of, that’s probably the right call, yes.

ljharb · 2017-08-09T17:47:38Z

As long as it's a clear decision one way or the other, I'm happy :-) it just can't be unspecified.

ljharb · 2017-08-09T17:48:13Z

007-extension-flag.md

+
+```sh
+# exits with an error
+node --entry-extension=json app.js


node --entry-extension=js app.js should then also error?

Might be a good example to add so that people don't think it's the mismatch that errors

Definitely a good example since most of the feedback so far has been above this :)

ljharb

What happens when a leading . is supplied?

What happens when an unknown extension is supplied?

Is there a way to list supported extensions on the CLI?

bmeck · 2017-08-09T20:35:13Z

What happens when a leading . is supplied?

Stream goes through CJS require.extensions then ESM import mechanics. It wouldn't find a ..js etc. extension and would fail.

What happens when an unknown extension is supplied?

Fails to load.

Is there a way to list supported extensions on the CLI?

Not currently, but could be proposed.

bmeck · 2017-08-09T20:38:18Z

This change does not attempt to change workflow of how files are loaded. It just declares the mode rather than going through CJS always. See https://github.com/nodejs/node/blob/5fd2f03b16bfd6730fe82dc3217f1d05131b9615/lib/internal/bootstrap_node.js#L435 for some existing implementation details.

ljharb · 2017-08-09T21:16:53Z

It seems like node --entry-extension=foo should fail immediately if foo isn't in require.extensions, and ideally would print out Object.keys(require.extensions) in the error message.

bmeck · 2017-08-09T21:19:14Z

@ljharb I am hesitant to do that error behavior since people could certainly add to the list using --require. Also, require.extensions is not used in the ESM logic.

ljharb · 2017-08-09T21:21:03Z

@bmeck in that case i'd expect the list to be runtime-computed, so if they'd added to the list, it would become a valid option.

However it's implemented, I think it'll be important to fail-fast when an invalid extension is supplied, and make sure the error message is meaningful and actionable.

ljharb · 2017-08-27T16:22:56Z

007-extension-flag.md

+
+### Early Errors
+
+Any unknown file extension should prevent the main entry point to the program from executing anything. Preloaded files such as using `--require` should continue to load normally.


Is there any concept of preloading files, but with a different entry extension? In other words, --import to match --require?

@ljharb not currently, use a wrapper for now. --require uses file paths always, so file extensions are always included. There are some odd problems with naming here, and some timing differences due to ESM being async that I think are fine to put off for a future time.

ah, so --require file.mjs would work as expected?

maybe? require('./foo.mjs') throws so the naming is a bit odd but since CLI arg for main file to run accepts .mjs it should work fine I would expect.

Correct, but require() has synchronous code boundaries to deal with. We have more freedom in how we define preload's interactions.

Perhaps we should have --import alias to --require though, for posterity and to avoid confusion. That being said, -i is already used.

IDK, --import seems fine and can use the module resolution of ESM rather than CJS then ESM

Fishrock123

Seems good overall. Have some comments.

I think this could be a place to define how -r works with non-Script goal programs, but I wouldn't be opposed to having that discussion in a different place either.

Fishrock123 · 2017-08-29T21:39:40Z

007-extension-flag.md

+
+## Description
+
+The Node CLI currently accepts input in both filename (`node app.js`) and opaque text stream form (`node -e '123'` and `node <app.js`). This behavior always results in running the stream as a CommonJS goal. With the upcoming usage of ESM and WASM there will be cases where developers wish to pipe other forms of text to the CLI.


Script goal and maybe also other program forms to the CLI

On second thought, I suppose that last one could also be clarified as source text if that is more consistent.

Fishrock123 · 2017-08-29T21:42:24Z

007-extension-flag.md

+
+The Node CLI currently accepts input in both filename (`node app.js`) and opaque text stream form (`node -e '123'` and `node <app.js`). This behavior always results in running the stream as a CommonJS goal. With the upcoming usage of ESM and WASM there will be cases where developers wish to pipe other forms of text to the CLI.
+
+This proposal is to implement an `--entry-extension` CLI flag for the cases which may want to use a stream that does not have a file extension.


If we are defining the name here, might be worthwhile to also specify --ext as a shorter-hand. People will want to see using it as reasonable UX.

do we have any abbreviates -- flags?

Unsure but I don't really see an issue with it.

What about -x ?

Could use that, I suppose. Does it have any common UNIX meaning it might be confused with?

no , http://tldp.org/LDP/abs/html/standard-options.html

Fishrock123 · 2017-08-29T21:45:18Z

007-extension-flag.md

+
+### Userland Extensions
+
+Some libraries extend `require.extensions` with new extensions. These libraries should be considered when determining the list of extensions allowed in `--entry-extension`.


How would this work? Only for preload modules I suppose?

Yep. Only preload would affect this.

Fishrock123 · 2017-08-29T21:47:59Z

007-extension-flag.md

+
+### Early Errors
+
+Any unknown file extension should prevent the main entry point to the program from executing anything. Preloaded files such as using `--require` should continue to load normally.


Correct, but require() has synchronous code boundaries to deal with. We have more freedom in how we define preload's interactions.

Perhaps we should have --import alias to --require though, for posterity and to avoid confusion. That being said, -i is already used.

Fishrock123 · 2017-08-29T21:48:55Z

007-extension-flag.md

+
+## Alternate Possibilities
+
+Some alternate possibilities exist that might be relevant. `--entry-url` for example could be used to provide an `import.meta.url` properly while also providing the pathname that contains an extension. However, since URLs are not mandated to have file extensions this might be for nothing. Applications can also access `process.cwd()` to recreate similar data to `import.meta.url`.


Seems far less intuitive?

yup, not suggested.

MylesBorins · 2017-11-29T05:33:03Z

@bmeck do you think it makes sense to close this as we are no longer using the eps process?

bmeck · 2017-11-29T06:03:32Z

@MylesBorins yes, as I presumed all EPs would be considered archived I didn't touch it.

styfle · 2017-11-29T20:21:28Z

007 is dead

See what I did there? 😄

......I'll show myself out now 🏃 🚪

007: --entry-extension CLI flag proposal

5903611

bmeck requested review from Fishrock123 and MylesBorins August 9, 2017 14:32

ljharb suggested changes Aug 9, 2017

View reviewed changes

collision with file path CLI form

4592cd0

ljharb reviewed Aug 9, 2017

View reviewed changes

another example of collision

5d72610

ljharb reviewed Aug 9, 2017

View reviewed changes

address @ljarb s review

6ad705d

ljharb approved these changes Aug 27, 2017

View reviewed changes

Fishrock123 reviewed Aug 29, 2017

View reviewed changes

bmeck mentioned this pull request Sep 12, 2017

BREAKING: deprecate loading files with unknown or missing extensions nodejs/node#15365

Closed

3 tasks

Fishrock123 mentioned this pull request Sep 18, 2017

Consider additive systems for importing ES Modules ayojs/ayo#56

Open

targos mentioned this pull request Oct 30, 2017

node --experimental-modules does not allow running files without an extension nodejs/node#16605

Closed

bmeck closed this Nov 29, 2017


		### Early Errors

		Any unknown file extension should prevent the main entry point to the program from executing anything. Preloaded files such as using `--require` should continue to load normally.


		## Description

		The Node CLI currently accepts input in both filename (`node app.js`) and opaque text stream form (`node -e '123'` and `node <app.js`). This behavior always results in running the stream as a CommonJS goal. With the upcoming usage of ESM and WASM there will be cases where developers wish to pipe other forms of text to the CLI.


		The Node CLI currently accepts input in both filename (`node app.js`) and opaque text stream form (`node -e '123'` and `node <app.js`). This behavior always results in running the stream as a CommonJS goal. With the upcoming usage of ESM and WASM there will be cases where developers wish to pipe other forms of text to the CLI.

		This proposal is to implement an `--entry-extension` CLI flag for the cases which may want to use a stream that does not have a file extension.


		### Userland Extensions

		Some libraries extend `require.extensions` with new extensions. These libraries should be considered when determining the list of extensions allowed in `--entry-extension`.


		## Alternate Possibilities

		Some alternate possibilities exist that might be relevant. `--entry-url` for example could be used to provide an `import.meta.url` properly while also providing the pathname that contains an extension. However, since URLs are not mandated to have file extensions this might be for nothing. Applications can also access `process.cwd()` to recreate similar data to `import.meta.url`.

Uh oh!

Conversation

bmeck commented Aug 9, 2017

Uh oh!

bmeck commented Aug 9, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ljharb left a comment

Choose a reason for hiding this comment

Uh oh!

bmeck commented Aug 9, 2017

Uh oh!

matthewp commented Aug 9, 2017

Uh oh!

matthewp commented Aug 9, 2017

Uh oh!

rauschma commented Aug 9, 2017

Uh oh!

bmeck commented Aug 9, 2017

Uh oh!

rauschma commented Aug 9, 2017

Uh oh!

ljharb commented Aug 9, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ljharb left a comment

Choose a reason for hiding this comment

Uh oh!

bmeck commented Aug 9, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bmeck commented Aug 9, 2017

Uh oh!

ljharb commented Aug 9, 2017

Uh oh!

bmeck commented Aug 9, 2017

Uh oh!

ljharb commented Aug 9, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Fishrock123 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

bmeck commented Aug 9, 2017 •

edited

Loading

bmeck commented Aug 9, 2017 •

edited

Loading