Write maid scripts to package.json

[zephraph]

Fixes #24

Adds the ability to write all maid tasks out to the package.json for easier consumption of tasks.

• add cli command
• implement script writer
• document command
• add lint-staged example
• dogfood setup
• account for pre/post scripts
• tests

[zephraph]

Okay, so I've made definite progress. The core of the functionality is there and the project itself is using it. There are still some outstanding issues though.

1. when pairing this up with lint-staged the maidfile is what will trigger the script update... but the package.json is the file that will change. How do we signify that a git add should happen?
2. I implemented this as a global option, but I'm not convinced it shouldn't just be a command... I started down that path, but I backtracked because I didn't want to pollute the command space.

[zephraph]

This really gives me pause... the more I think about it the more I think this should be a command

[zephraph]

I should probably break this function down.

[zephraph]

🎉 AUTOMAGICALLY GENERATED 🎉

[egoist]

why disallow this 🤔

[zephraph]

in the updateScripts method, I'm passing all the arguments through transparently. If I allowed this I'd have to find the input and remove it before writing to the package.json.

So... laziness. I can remove it. Point might be moot if this turns into its own command though.

[zephraph]

[zephraph]

Thought of another issue. pre and post tasks will conflict with the package.json's version.

Let's say there are two tasks... prebuild and build. Running yarn build would trigger yarn prebuild which would run the prebuild task... but that task would be ran again by maid before build started. So we may need to filter those out before writing the tasks.

[tunnckoCore]

Remove the implementation of pre and post and rely on the scripts for that?

Few positives from that:

1. lower code
2. battle tested handling
3. better "out of the box behaving" - so no need to write "run that before this and after this" kinda sentences. Just say users that if they want hooks, they can use: a] package scripts for hooks - so will be able to run maid build and that will executethe prebuild script that points to maid test, or b] just call the desired tasks in what order they want - e.g. maid test build to run test then build task.

The 3.a may be a bit trickier probably, but second one is whole lot easier and obvious and familiar.

So let's rephrase...

Scenario 1

User syncs scripts.

{
  "scripts": {
    "test": "maid test",
    "build": "maid build"
  }
}

If he want to run test before build would just run maid test build (npx maid test build or yarn maid test build) which requires the implementation for running multiple tasks, a la gulp? Btw, comma separated tasks.

It's clean, obvious, familiar, less verbose (on tasks and scripts definition) and the multiple tasks impl would be smaller.

Scenario 2

User syncs the scripts (with that PR's command) with specific flag (can't come name for that flag to my mind ;d). This command is implemented with the current idea of defining sentences, respect them (only?) when ran with that flag...

maid update-scripts --hooks

generates

{
  "scripts": {
    "prebuild": "maid test",
    "build": "maid build"
  }
}

from this maid file

## build

Build our main app

<!-- Following line is a maid command for running task -->
Run task `test` before this

\`\`\`bash
# note that you can directly call binaries inside node_modules/.bin
# just like how `npm scripts` works
babel src -d lib
\`\`\`

## test

Test all the things.

\`\`\`bash
ava tests
\`\`\`

foo bar

doh how ugly is my last code block... how you handle the markdown in markdown situation, here in github issues?! 🤣

[zephraph]

@egoist I would actually be all for removing the pre and post commands... but I understand why they're there and I'm not looking to make that change in this PR.

I added logic to check every task that starts with pre or post against the list of tasks. If the a task exists that is the representative base task (i.e minus pre or post) then it won't write the task.

That means if there's a prebuild and build command then only build will be written. But if a precommit task exists, but commit doesn't, then precommit will still be written.

[zephraph]

@egoist I still need to add tests but this works/is ready for review.