🛠 📦
@gsmlg/scripts CLI toolbox for common scripts for my projects
Commands
build
format
lint.js
pre-commit
test
typecheck
validate
[![Build Status][build-badge]][build] [![Code Coverage][coverage-badge]][coverage] [![version][version-badge]][package] [![downloads][downloads-badge]][npmtrends] [![MIT License][license-badge]][license] ![All Contributors][all-contributors-badge] [![PRs Welcome][prs-badge]][prs] [![Code of Conduct][coc-badge]][coc]
The problem
I do a bunch of open source and want to make it easier to maintain so many projects.
This solution
This is a CLI that abstracts away all configuration for my open source projects for linting, testing, building, and more.
Table of Contents
Installation
This module is distributed via [npm][npm] which is bundled with [node][node] and should be
installed as one of your project's devDependencies
:
npm install --save-dev @gsmlg/scripts
Usage
This is a CLI and exposes a bin called @gsmlg/scripts
. I don't really plan on
documenting or testing it super duper well because it's really specific to my needs.
You'll find all available scripts in src/scripts
.
This project actually dogfoods itself. If you look in the package.json
, you'll find
scripts with node src {scriptName}
. This serves as an example of some of the things you
can do with @gsmlg/scripts
.
Overriding Config
Unlike react-scripts
, @gsmlg/scripts
allows you to specify your own configuration for
things and have that plug directly into the way things work with @gsmlg/scripts
. There
are various ways that it works, but basically if you want to have your own config for
something, just add the configuration and @gsmlg/scripts
will use that instead of it's
own internal config. In addition, @gsmlg/scripts
exposes its configuration so you can
use it and override only the parts of the config you need to.
This can be a very helpful way to make editor integration work for tools like ESLint which require project-based ESLint configuration to be present to work.
So, if we were to do this for ESLint, you could create an .eslintrc
with the contents
of:
{"extends": "./node_modules/@gsmlg/scripts/eslint.js"}
Note: for now, you'll have to include an
.eslintignore
in your project until this eslint issue is resolved.
Or, for babel
, a .babelrc
with:
{"presets": ["@gsmlg/scripts/babel"]}
Or, for jest
:
const { jest: jestConfig } = require('@gsmlg/scripts/config');
module.exports = Object.assign(jestConfig, {
// your overrides here
// for test written in Typescript, add:
transform: {
'\\.(ts|tsx)$': '<rootDir>/node_modules/ts-jest/preprocessor.js',
},
});
Note:
@gsmlg/scripts
intentionally does not merge things for you when you start configuring things to make it less magical and more straightforward. Extending can take place on your terms. I think this is actually a great way to do this.
TypeScript Support
If the tsconfig.json
-file is present in the project root directory and typescript
is a
dependency the @babel/preset-typescript
will automatically get loaded when you use the
default babel config that comes with @gsmlg/scripts
. If you customized your
.babelrc
-file you might need to manually add @babel/preset-typescript
to the
presets
-section.
@gsmlg/scripts
will automatically load any .ts
and .tsx
files, including the default
entry point, so you don't have to worry about any rollup configuration.
If you have a typecheck
script (normally set to @gsmlg/scripts typecheck
) that will be
run as part of the validate
script (which is run as part of the pre-commit
script as
well).
TypeScript definition files will also automatically be generated during the build
script.
Inspiration
This is forked from kcd-scripts.
LICENSE
MIT