You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL;DR: anything that is related to use interaction (logging in the console, etc) should be done in npm scripts, not only in binaries, the latter being only pure bridges to scripts.
The current project architecture contains several parts:
the source code
general documentation
package's scripts
package's binaries
...
This issue talks about something at package level
The package is done using the npm system, which allows doing many things.
One of those thing is to be able to define scripts, which are regular shell commands, and which can be run with the command: npm run-script <script-name> (some standard scripts with specific names can even be directly run like this: npm <script-name>).
Our choice is to — as much as we can — always invoke a JavaScript file with Node.js, and those files are put under scripts. Then they do the stuff we expect from them, like for instance building parts of the project, watching, etc.
npm also provides a feature which is to define binaries, which are available as system shell scripts when the package is installed. Each binary got a name, and a path to a JavaScript file to be invoked with Node.js (here there is no choice, no custom command possible): those files are put under the bin folder.
In order to remain consistent and to ease development, we decided to make binaries as pure bridges to npm scripts: indeed if a user wants to do something that a binary can do, the developer should be able to do it too, through npm run-script.
One inconsistency is the following however:
Both techniques allow to execute code from the command line, for convenience. They are both intended for users, even if the users are not the same.
The problem is that user interaction has been put only in binaries implementation and not in scripts. That should be fixed, and binaries would then remain pure bridges to those scripts.
The text was updated successfully, but these errors were encountered:
TL;DR: anything that is related to use interaction (logging in the console, etc) should be done in npm scripts, not only in binaries, the latter being only pure bridges to scripts.
The current project architecture contains several parts:
This issue talks about something at package level
The package is done using the npm system, which allows doing many things.
One of those thing is to be able to define scripts, which are regular shell commands, and which can be run with the command:
npm run-script <script-name>
(some standard scripts with specific names can even be directly run like this:npm <script-name>
).Our choice is to — as much as we can — always invoke a JavaScript file with Node.js, and those files are put under
scripts
. Then they do the stuff we expect from them, like for instance building parts of the project, watching, etc.npm also provides a feature which is to define binaries, which are available as system shell scripts when the package is installed. Each binary got a name, and a path to a JavaScript file to be invoked with Node.js (here there is no choice, no custom command possible): those files are put under the
bin
folder.In order to remain consistent and to ease development, we decided to make binaries as pure bridges to npm scripts: indeed if a user wants to do something that a binary can do, the developer should be able to do it too, through
npm run-script
.One inconsistency is the following however:
Both techniques allow to execute code from the command line, for convenience. They are both intended for users, even if the users are not the same.
The problem is that user interaction has been put only in binaries implementation and not in scripts. That should be fixed, and binaries would then remain pure bridges to those scripts.
The text was updated successfully, but these errors were encountered: