Deno: Deno npm scripts substitue

[CeamKrier]

Since it is not necessary to have package.json file with deno, how can I as a developer have a similar experience just as we have with npm scripts in package.json while using node.js environment?

[nayeemrmn]

Duplicate of #47, #3777.

[CeamKrier]

Duplicate of #47, #3777.

Actually, no. I am not asking to have a centralized configuration file but rather options to abstract my frequently used commands while working with deno.

I don't want to re-run long and eye-straining command like deno run --allow-read --allow-net --reload server/index.ts.

I asking that because I wanna know if there is something considered by the maintainers about that. And if not, I am open to their suggestions.

[nayeemrmn]

Sorry I guess I misread "npm scripts". Yes it has been discussed.

See https://github.com/denoland/deno/issues/2584#issuecomment-550473018, #3861, https://github.com/denoland/deno/issues/3861#issuecomment-598213790.

Deno wants things like this to be in userland, but adding a module for this purpose in std is not being considered any time soon.

[kitsonk]

Also to state, deno install will "save" the flags inside the init script.. in many cases it is better than npm scripts.

[gsklee]

@kitsonk you mean running deno install and somehow it will know deno run has to be executed with those cli flags?

[kitsonk]

@gsklee not exactly, it will install a shell script/cmd that will invoke deno run someScript.ts with those flags, all under a new command...

[CeamKrier]

I checked the suggestion of @kitsonk and indeed the deno install command gives you an executable file according to your OS.

For example:
deno install colors https://deno.land/std/examples/colors.ts downloads the executable as

% generated by deno install %
@deno.exe "run" "https://deno.land/std/examples/colors.ts" %*

So I tuned that according to my needs and created an executable and named it as scripts.cmd (for Windows) on the project's root.

@echo off

if [%1] == [] ( @echo on && echo Please specify your command. && @echo off  )
if [%1] == [run] ( @deno.exe "run" "--allow-net" "--allow-read" "index.ts" ) else ^
if [%1] == [clean-run] ( @deno.exe "run" "--allow-net" "--allow-read" "--reload" "index.ts" ) ^
else ( @echo on && echo Supplied arguments not matched with available ones. )

And run this on command line with

./scripts.cmd run

[galkowskit]

What is wrong with a Makefile? It is known across stacks, it is not technology-specific.

[umbopepato]

@CeamKrier take a look at https://github.com/umbopepato/velociraptor. It provides a similar experience to package.json scripts with some added features like deno cli options, env vars and more

[ry]

This is out of scope. I appreciate that this is useful functionality but I don't think it belongs in deno itself.

[coolemur]

@ry Hello.

How is ability to create shorthands for long commands out of scope ? I think this is exactly the thing that belongs to deno itself. Because community already created at least 2 tools to solve this issue (denox and velociraptor).

I think deno developers should review this issue again. This will always be an issue when devs want to have shorter commands. And if deno had an approved and documented way to do so - this would solve few problems:

• all deno projects would have same way to define command shorthands;
• no more new third party libraries that tries to solve this issue;
• no more questions from new deno devs;

I think this functionality is not just useful but it belongs to standard libraries/project configuration and documentation.

[nayeemrmn]

@coolemur It's out of scope because any CLI tool would benefit from this kind of solution, and indeed any solution would naturally work for every CLI tool. The "scripts" field of package.json works just as well for Deno commands as it does for Node commands, try it. It's just generic cross-platform shell scripting.

[coolemur]

@nayeemrmn This is my point. You just gave me yet another one solution. Wouldn't it be great to have a standard way to use short commands in deno? So in future deno community won't have tons of different ways to run projects ?

The fact that "any CLI tool would benefit from this kind of solution" doesn't solve "shorthands for long commands would save time when running projects" issue.

[nayeemrmn]

The fact that "any CLI tool would benefit from this kind of solution" doesn't solve "shorthands for long commands would save time when running projects" issue.

I didn't say it solved it. I'm explaining why we shouldn't solve it. Wouldn't it be great to have a standard way to use short commands for _everything_ instead of each runtime inventing its own solution? Let's not help perpetuate that.