How do we run scripts in the project?

[jonrohan]

Currently in the project we multiple methods for running scripts, but none of them align or agree on what is run. Here are some of the ways I've found.

1. Rakefile rake tasks
2. /script/ folder
3. npm package.json scripts
4. .vscode/tasks.json

I want to propose that we unify around a standard, and make sure all secondary script runners run the default.

Standard runner?

I believe this should be Rakefile because the project is mostly a Ruby on Rails project. But I'm curious to hear what others think here.

If the default is Rakefile and we want to be able to run a npm specific task, how should they connect?

For example let's take a lint:eslint command. If the binary we need to run is eslint 'app/components/**/*.ts'. Assuming we want the same command in all systems:

Rakefile

Runs the required lint command

bundle exec rake lint:eslint 
runs: => eslint 'app/components/**/*.ts'

package.json

Runs the preferred script platform, rake? Or should the both run the commands in the same way?

npm run lint:eslint
runs: => bundle exec rake lint:eslint

[mxriverlynn]

TL;DR

i'm not sure i agree that we need a standard. but if we decide we do need one, i'd be against using rake or npm as that standard. i'd rather use scripts/* for reasons outlined below.

that said, I'd rather see good documentation than any attempt to consolidate on a single standard for writing and/or running scripts

The Long Version

every tool has trade offs. we should be able to pick the one that's best for a situation. it also seems a little odd to load up ruby and rake and all that, just to shell out to commands that only need node modules, or don't need need ruby or node at all. or the same for loading npm to shell out to rake, etc.

it also gets more complicated when adding thor scripts into the mix for component_generator and component_status_migrator. these scripts need command line params passed in. you can pass in params to rake in a couple of different ways, but they all have their own oddities and difficulties compared to the standard linux style params that thor offers. and as soon as we make an exception for thor scripts or any other type of script, we're right back at the starting point where there will always be exceptions and we end up with a glob of different tools anyways.

if we have to pick a standard, i would rather see script/* as the default. this at least gives us flexibility in what language we use for a script while also standardizing where things are run. many of these scripts will be little more than a call out to npm run or bundle exec rake. but i can get behind that idea since i can write a bash script that executes the same way as writing out the command in my terminal prompt.

but even using script/* as the standard has trade offs. for example, we standardize it, which is great. but we have to enforce that standard which means at a minimum we have to clearly and thoroughly document the standard and how we want to handle things that are little more than pass-through scripts. it probably doesn't make sense to try and write a linter to ensure every command in rake, npm, thor, etc, has an equivalent script/*, but without that it's easy to miss adding or updating and we end up with scripts being out of date compared to the tools that are being used.

in the end, any choice that is made in how we run scripts will have trade offs (including leaving things as is). but every solution we come up with to standardize things comes with a minimum amount of documentation to ensure everyone understands what's going on and how to follow the standard.

none of these options solve the core problem of having to know at least three or four different scripting systems to effectively work in PVC (bash, npm scripts, rake scripits, thor scripts). and that's not a "problem" i think we should try and solve. it's a choice of using the right tool for the job with the constraints of each task we need to perform (which language / package / system has the tools we need, etc?).

so if we're going to look at trade offs when each possible solution listed here has potentially as many or more quirks as we currently deal with, and each possible solution listed requires a minimum amount of documentation, then i'd say we forget trying to standardize how scripts are run. instead, we should look at the one common thread in all of this.

My Recommended Solution

focus on writing easy to find, read, and understand documentation for every script in a centralized location for the project. this will likely be a markdown document in the doc folder or some other place where we can convert it into a page that shows up on the primer.style site