zapier-scripts

Zapier Frontend scripts 🤖

This package is owned by the foundations team (#team-foundations), but is deprecated.

The end-goal of this project is to have a CLI executable to be used by Zapier projects that abstracts away configuration for linting, testing, formatting, building, etc.

Note: although this repository is private, the NPM package it publishes to is public.

Installing

yarn add zapier-scripts --dev

Folder structure convention

zapier-scripts assumes your project will have the following folder structure:

.
├── package.json
├── /node_modules
├── /dist
│   └── bundle.js
├── /src
│   ├── /some-folder
│   │   └── bar.js
│   │   └── bar.test.js
│   └── index.js
└── /tests (legacy, recommend using side-by-side *.test.js)
    ├── /some-folder
    │   └── bar.js
    └── index.js

Adopting a folder structure convention allows us to leverage powerful out-of-the-box defaults, as you'll see below.

Usage

zapier-scripts [script] [args]

Where args are any of the args that you can pass to the inner tool that the script wraps (including file paths), and script can be one of the built-in scripts below:

| Script | Description | | --------------- | ------------------------------------------------------------------ | | lint | 👕 Lints code using ESLint | | test | 🚨 Runs tests using Jest | | format | 💅 Formats code using prettier | | format-staged | 💅 Run prettier automatically on your staged files before a commit | | validate | 🔍 Runs lint, test and format in parallel. |

All scripts can be called with no extra arguments and zapier-scripts will use sane defaults, with no extra configuration needed on your part.

Overriding configuration defaults

zapier-scripts will use sane defaults unless it finds a config file in your project's root for that specific tool. In that case, your config file takes precedence.

For example, if you don't have an .eslintrc.js (or .eslintrc.json) file in your project root, zapier-scripts defaults to using its internal config file (that extends from eslint-config-zapier).

Note that zapier-scripts does not do config merging. This is by design. If you want to have a custom config file that inherits from the default zapier-scripts config, remember to extend from it. For example, for ESLint:

module.exports = {
  extends: [require.resolve('zapier-scripts/src/config/eslint.js')],
  // your custom config stuff goes here
};

Editor integrations

Unfortunately, most editor integrations will only work if the config file is in the project's root. Luckily, it's easy to get around this: simply create a config file in your project's root that inherits from the default zapier-scripts' config.

For example, to add ESLint editor integration, add a file called .eslintrc.js to your project root with the following content:

module.exports = require('zapier-scripts/src/config/eslint');

If you want prettier integration, add a file called prettier.config.js to your project root with the following content:

module.exports = require('zapier-scripts/src/config/prettier');

Using format-staged to automatically format all staged files before a commit ✨💅

To run prettier on all staged files automatically before a commit, add a precommit script to your package.json like the following:

"scripts": {
  "precommit": "zapier-scripts format-staged"
}

Support

• OS X
• npm > 5

Development

If you want to test this package with another package in the monorepo, you don't have anything to do. Your changes will be reflected immediately.

If you want to test this package with an external project, you can test it by yarn installing from a local path. yarn linking won't work since it doesn't trigger the postinstall script that installs the pre-commit hook.

mkdir zapier-scripts-testing
cd zapier-scripts-testing
yarn install ../zapier-scripts

TODO Checklist

• [ ] Add tests
• [ ] Add documentation sections for each script
• [ ] Refactor code to ES6 and add babel support

Contributing & Publishing

When working on a PR, include a description of what changed in the vNext section of the CHANGELOG. If there's no vNext section, add one.

Before publishing a new version, rename the vNext section of the CHANGELOG with the correct version number you're about to publish, then add a new empty vNext section at the top. Then:

git add CHANGELOG.md
git commit -m "Update CHANGELOG"
npm version [major|minor|patch]
git push --follow-tags

Once your PR has been merged to develop, you can publish the package with:

npm publish

Inspiration

This is inspired by kdc-scripts and react-scripts.