Can we drop the "run-script" requirement for custom npm scripts?

350 views
Skip to first unread message

Andrew Pennebaker

unread,
Apr 23, 2013, 1:13:42 PM4/23/13
to nod...@googlegroups.com
It would be nice to not have to type "run-script" to refer to custom scripts. Some package managers like leiningen expose custom scripts without any fuss ("lein cust"). Could we do the same with NPM ("npm cust")?

Yes, security may be a concern, for package.json files that attempt to overwrite NPM built-ins like "install", "update", "help", etc. We have several options for handling collisions. My solution is for NPM to strip out scripts that would overwrite these built-ins, and print a warning along the lines of:

"WARN: package.json attempted to overwrite npm built-in script "install". Ignoring custom script..."

Just an idea.

Martin Wawrusch

unread,
Apr 23, 2013, 1:17:48 PM4/23/13
to nod...@googlegroups.com
+1 for that.


--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
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?hl=en
 
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



Kevin Swiber

unread,
Apr 23, 2013, 1:22:14 PM4/23/13
to nod...@googlegroups.com
Note that `npm run` is an alias for `npm run-script`. That should reduce the pain by 70%. :)

--
Kevin Swiber
@kevinswiber
https://github.com/kevinswiber

greelgorke

unread,
Apr 23, 2013, 3:40:41 PM4/23/13
to nod...@googlegroups.com
a simple alias npmr npm run-script ?

Luke Arduini

unread,
Apr 23, 2013, 4:29:11 PM4/23/13
to nod...@googlegroups.com
I don't think this is a good idea. It doesn't solve any actual problem and potentially creates problems for package maintainers in the future.


Andrew Pennebaker

unread,
Apr 23, 2013, 5:04:38 PM4/23/13
to nod...@googlegroups.com

This solves the unintuitive problem of npm scripts. A user follows instructions for writing a "test" script, and everything seems to work. Then he writes another script, and it doesn't, and he wonders why. He takes time away from getting actual work done to lookup why his script won't run. Surprise, you have to type a bunch more characters in order to access custom scripts.

This workflow might have made sense if custom scripts were placed inside a "run-script" key, but they're not, and the distinction between writing a "test" script and another script is needlessly conceptually separated. Make doesn't require "run-script" to execute a task, why should npm?

npm is converging towards dependent tasks, where such distinctions do not make sense. npm is more than just a package manager, it's a build tool, let's embrace this.

You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/b1Yyh0jkzgw/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.

Luke Arduini

unread,
Apr 23, 2013, 5:11:05 PM4/23/13
to nod...@googlegroups.com
On Tue, Apr 23, 2013 at 5:04 PM, Andrew Pennebaker <andrew.p...@gmail.com> wrote:

 He takes time away from getting actual work done to lookup why his script won't run.

As in, spending a few minutes reading the documentation on the software he or she frequently uses?

Andrew Pennebaker

unread,
Apr 23, 2013, 5:32:57 PM4/23/13
to nod...@googlegroups.com

The more documentation required, the less intuitive the interface.

Luke Arduini

unread,
Apr 23, 2013, 6:05:20 PM4/23/13
to nod...@googlegroups.com
Yes, of course. But with any development tool, there is a time cost associated with reading documentation (and I think it would be a difficult argument to effect that reading documentation for a tool one frequently uses is a cost without benefit).

My personal opinions aside, the major cost for dropping the [run-script] requirement would be reduced flexibility if npm were to add more built-in commands in the future. 'Namespacing' them under [run-script] seems like a logical choice, to not cage potential future new commands for npm.


You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.

Martin Wawrusch

unread,
Apr 23, 2013, 6:08:10 PM4/23/13
to nod...@googlegroups.com
Why does it have to be that complicated? Built in commands always take precedence, if there is a conflict than npm will print a nice fat warning saying that an internal command overshadows a custom script

Arnout Kazemier

unread,
Apr 23, 2013, 6:18:55 PM4/23/13
to nod...@googlegroups.com
You are trying to fix a non existing problem. Just create an alias to `npm run` and be done with it.
Theres nothing wrong with using `npm run` and the solution that's suggested here only adds more
un-needed complexity.

Founder: Observe.it

Lead Software Engineer: Nodejitsu.com


Twitter: @3rdEden

Github: @3rd-Eden

Skype: arnoutkazemier

Mobile: +31623254031

--

Isaac Schlueter

unread,
Apr 23, 2013, 6:34:08 PM4/23/13
to nodejs
I'm not actually interested in supporting any scripts other than
`test` and `prepublish`. Anything else is a mistake that we only
support for backwards compatibility.

So, what I'm saying is, thanks for the suggestion. We're not going to
make that change.
Reply all
Reply to author
Forward
0 new messages