Use `start` script about pkg HOT 13 CLOSED

Hello, is it possible to run a global CLI, like "adonis migration: run" from pkg side?

from pkg.

That is, you'd like to just run pkg without specifying a filename? An interesting idea. The problem with start is that it's an arbitrary shell command, not a JavaScript entry point. The main entry point could perhaps be more appropriate since it does point to a JavaScript file.

from pkg.

Or some property in the package.pkg config object, like "entrypoint".

from pkg.

You can always specify entry point javascript file explicitly in CLI instead of passing path to package.json.

from pkg.

Thoughts on using the main field?

I know it's primarily used in libraries, but it would be a good fit for pkg as well.

from pkg.

from pkg.

Sorry, i can not get why you don't like bin field. Pkg's purpose is to (mostly) emulate npm i something -g tool installation and usage scenario. Since globally installed tool uses bin field, the idea behind pkg was to use bin field as well.

from pkg.

And yeah, you can specify several subfields in bin field. Pkg will use one that's name matches with name field of package.json.

from pkg.

@igorklopov Ahhh I did not realize that the bin entry was already supported. I see now that it's also documented in the README.

I'm closing since I don't think it makes sense to duplicate functionality when there is already a mechanism to specify entry point in the package.json. Thank you for the suggestion though!

from pkg.

from pkg.

@piranna The "start" script is used for starting servers, not CLI applications. The bin field is absolutely used for CLI applications, and npm encourages this with the --global flag installing into your $PATH.

pkg mapping to bin is perfect.

from pkg.

npm start is also used to start cli applications too, I have seen using server.js just for this everywhere. Also, since several years ago usage of --global and globally installed modules are absolutely deprecated, so that's not the point. You can use bin, but that's a mapping of the executables that offer that module, that can be several of them, and there's no requeriment that any of them has the same name of the current module, so blindly trust on that field is a bad usage and a bug according to the spec. As I said before, better alternatives are to use standard start script, or if not following standard practices, add a new custom field on package.json file just for this.

from pkg.

Great idea with npm start 👍

Implementing that allows us easily pack micro-services to single executable.

UPD: As quick fix, it possible to use full path to runner in bin script, works well in my case.
"bin": "node_modules/micro-bot/bin/micro-bot".

from pkg.