[nodejs] Things I'd like to see happen for node

[Jonas Pfenniger (zimbatm)]

This is my own TODO list. I've you want to make some part of it,
you're welcome :)

Command-line
------------

There are some highly useful features that makes a command-line
executable complete:

* support of NODE_LIB environment variable to specify load-paths
* -I "load_path" to add a path to the load-paths
* -e, --eval "expression" for inline script execution
* feeding script trough STDIN (when '-' is a script file)
* NODE_OPT to set default options
* --debug to enable sys.debug() outputs

Runtime
-------

* event-debug: to replace putting debug messages everywhere in your
code. prints all events emitted by libev.
* consistant handling of exceptions: it's getting better
* a working debugger
* useful 1st class globals : sys module should probably be included
automatically in the entry-point script

Regarding the last point, please view it as a pragmatic approach.
Modules should not have any globals except the built-ins, module and
require. But, on the other side, I think this rule should not apply to
the entry-point script. There is a difference when you want to build a
redistribuable module and when you quickly fletch a small script to do
something. In the first case it must be highly conforming, on the
other you're only interested in the result.

Library / Modules system
------------------------

* stop polluting the global namespace, put node-specific modules in
"node/..." and CommonJS modules in "/"
* remove the "process" global (or make it only accessible to the code-modules)
* consistent handling of deprecation : externalize deprecation and
removal warnings into it's own library
* node is not only for the web : make it more useful for the desktop
and command-line

That's all for now :)

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[Isaac Schlueter]

Some of these are already possible.

On Sat, May 22, 2010 at 05:11, Jonas Pfenniger (zimbatm)
<jo...@pfenniger.name> wrote:
> * support of NODE_LIB environment variable to specify load-paths

It's $NODE_PATH. It works today.

> * -I "load_path" to add a path to the load-paths

NODE_PATH=/some/path:/some/other/path node program.js

> * -e, --eval "expression" for inline script execution
> * feeding script trough STDIN (when '-' is a script file)

Yeah, that'd be cool.

> * NODE_OPT to set default options

Like which options?

> * --debug to enable sys.debug() outputs

./configure --debug && make && sudo make install
and then,
NODE_DEBUG=1 node program.js

> * event-debug: to replace putting debug messages everywhere in your
> code. prints all events emitted by libev.

+1, but this would be super noisy.

> * consistant handling of exceptions: it's getting better

Agreed.

> * a working debugger

Check out ndb.

> * useful 1st class globals : sys module should probably be included
> automatically in the entry-point script

-1. require("sys") is fine. Fewer auto-globals is good.

> * stop polluting the global namespace, put node-specific modules in
> "node/..." and CommonJS modules in "/"

You mean put node's builtins under the "node/" prefix? Or just node programs?

If it's the latter, you can do this today by just putting node things
in a subfolder.

> * remove the "process" global (or make it only accessible to the code-modules)

I'd prefer to have something like: var process = require("process");

> * consistent handling of deprecation : externalize deprecation and
> removal warnings into it's own library

Better yet, just remove all the deprecation warnings in 0.2.0.

> * node is not only for the web : make it more useful for the desktop
> and command-line

That's our job. There are a few modules out there that add cli sugar.
Having written a pretty extensive cli program in node myself, I gotta
say, it's not bad.

--i

[Isaac Schlueter]

On Sat, May 22, 2010 at 09:08, Isaac Schlueter <i...@izs.me> wrote:
>> * --debug to enable sys.debug() outputs
>
> ./configure --debug && make && sudo make install
> and then,
> NODE_DEBUG=1 node program.js

Whoops, I misunderstood you. You're talking about not allowing
sys.debug unless you have the debug flag set. That's an interesting
idea.

[Jonas Pfenniger (zimbatm)]

On Sat, May 22, 2010 at 6:08 PM, Isaac Schlueter <i...@izs.me> wrote:
> Some of these are already possible.
>
> On Sat, May 22, 2010 at 05:11, Jonas Pfenniger (zimbatm)
> <jo...@pfenniger.name> wrote:
>> * support of NODE_LIB environment variable to specify load-paths
>
> It's $NODE_PATH.  It works today.

Sorry it was a bit of a brain-dump, but apparently I brought some ideas too.

>> * event-debug: to replace putting debug messages everywhere in your
>> code. prints all events emitted by libev.
>
> +1, but this would be super noisy.

what would be event cooler, would be to telnet on a secret port when
your program is in a "wtf"-state, getting the last emitted event, and
then the stream of events.

>> * useful 1st class globals : sys module should probably be included
>> automatically in the entry-point script
>
> -1.  require("sys") is fine.  Fewer auto-globals is good.

It's more like auto-locals, since it wouldn't be available in any other module.

More importantly, I'd like to introduce that main-script / module distinction.

From my point of view, the module approach is right for distributing
libraries. All dependencies are clearly defined and fences are up.

On the other hand, it introduces an unnecessary overhead when writing
bash-like scripts. I remember the days where you could just
puts("something") in your script and it was nice. Now it's like you
had to source echo in your bash scripts.

Just to resume my point of view:

modules:
- no "process" global, maybe available trough require()
- no require.paths, or at least read-only
- fences up

main-script:
- useful global functions
- allowed to fiddle with require.paths
- no fences

Thanks for your input :)

[Isaac Schlueter]

On Sat, May 22, 2010 at 11:45, Jonas Pfenniger (zimbatm)
<jo...@pfenniger.name> wrote:
> More importantly, I'd like to introduce that main-script / module distinction.

We've been over this before on this list.

The "main-script" is src/node.js. Making the command line argument a
non-module would complicate things without providing any real benefit.

Thankfully, we don't have to agree. Due to the lightweight and
liberal nature of node's module system, and the flexibility of the
JavaScript language, it is entirely possible to write a loader program
on top of node that has pretty much any set of features you could
want. Just look at Nodules.

--i