Feature Request: Improve/update package.json to better reflect current project features and ease process of future project updates and overall maintenance.

[DaneTheory]

PROBLEM

• What To Update:
  Currently, the package.json for react-slingshot includes engine versions listed for Node and NPM, but not YARN even though YARN is fully supported by react-slingshot. See: yarn vs npm  #319 and Added yarn. #292. It's really just basic house cleaning that needs to be done. The project is widely used and it's important we don't overlook the little things.

• What To Improve:
  Currently, the list of available scripts in package.json are subject to a few notable restrictions. While there will, and always will be room for improvement, this speaks more so to the issue of overall maintainability/scalability. Restrictions worth noting are:

  • Scripts are written as they are in order to circumvent validation issues for improperly formatted JSON. JSON imposes strict format rules for strings and lacks flexibility in alteration like JavaScript. character escaping, line-breaks, etc. are things that can be accomplished, but the fixes needed to do so produce ugly, harder to read values.
  • Crafting scripts where complexity is needed for successful overall execution can be done, but are not exactly "easy" to implement. For example, in order to run a script that requires another script (or scripts) to run with it in parallel, as a synchronous step, or if the script needs an argument passed to it; currently accomplishing these things requires a dependency on an additional dev package concurrently the use of &&, the use of --. Along with the aforementioned example; piping, files paths, an additional dev dependency on rimraf, etc. are all things found currently in the scripts within package.json
  • It's easy and quick to add code bloat to the list of available scripts in any package.json. Creating scripts that need to run either in parallel or synchronously result in the creation of sub-scripts written using the script:script naming convention. Many times, some of these sub-scripts are never even intended for regular use. In the case of React-Slingshot, the issue gets taken even further because we also have scripts like "start-message" that no user ever needs to run because "prestart" runs this script on "start".
  • If a user needs to customize a particular script, say to include an environment variable that is added to their application at runtime; a scenario that is, in fact, very common, then the challenge they immediately face is how to add the changes they need without breaking script dependencies, script execution order, etc. This requires the user to begin a process of elimination with script hackery, read into the docs on what all individual scripts do, etc. all to get what they need done accomplished.

SOLUTION

• For "What To Update"
  Add yarn to the list of supported engines after first testing to finding an acceptable working version.
• For "What To Improve"
  When it comes to scripts, remove the concern of responsibility from package.json and abstract scripts into a file of their own, that can be written/crafted/documented/etc. in a much more flexible, maintainable manner. To do so, I propose the addition of the nps package to react-slingshot. See ADDITIONAL for link reference. nps can be included as a dependency to react-slingshot, or installed globally by the user. Personally, I favor including it with react-slingshot. The obvious reason is It does not add an additional step for the user to get started with react-slingshot. The obvious down-side being the requirement of an additional package as a dependency for react-slingshot. However, nps provides utility methods that not only add additional functionality we could benefit from, but also satisfy functionality we currently rely on other dependencies for, namely rimraf and concurrently. The scripts file nps uses is in JavaScript. Functions, strings, objects, everything you can do in JavaScript can be leveraged to create scripts. Yep. Everything. Execution of scripts using nps is still done via package.json, only instead of including sub-scripts or other unused scripts which add code bloat only the essential scripts users need are located in package.json. When it comes to script customization, user's will find that all script entries in the nps scripts file also provide a description as to what each script does. The addition of nps to react-slingshot is relatively straight forward. First, it's installed as a dependency. Then, create a JavaScript file (let's call it package-scripts.js) and place it in any preferred location within the react-slingshots directory hierarchy that makes sense. Within this file, an object composed of the scripts intended for project use are all written, documented, and can be customized to execute in whatever dynamic fashion so desired with functions and utilities. This object is exported as a module that nps recognizes. To run scripts, simply add the name of the desired script to the "scripts" object in package.json, passing in the string value as nps followed by the name of the script declared in package-scripts.js. For example, to run prestart, the resulting code in package.json would look like this:
  original:
  "prestart": "npm run start-message"
  new:
  "prestart": "nps prestart.message"
  For more complex demonstrations, refer to the package site provided in ADDITIONAL

ALTERNATIVES
I'm unaware of any packages offering similar functionality to that of nps, however an alternative would be introducing a task manager like Grunt/Gulp. However, I prefer the current react-slingshot approach to dealing with scripts and don't see a need for including a task-runner to the mix, of which nps is not.

ADDITIONAL
Link To nps:
https://www.npmjs.com/package/nps