---

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
• Usage
  • Overriding Config
  • TypeScript Support
• Inspiration
• Other Solutions
• Issues
  • Bugs
  • Feature Requests
• Contributors
• LICENSE

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)
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
: '<rootDir>/node_modules/ts-jest/preprocessor.js',
  },
});

Note: __INLINE_CODE_23__ 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 __INLINE_CODE_24__-file is present in the project root directory and __INLINE_CODE_25__ is a dependency the __INLINE_CODE_26__ will automatically get loaded when you use the default babel config that comes with __INLINE_CODE_27__. If you customized your __INLINE_CODE_28__-file you might need to manually add __INLINE_CODE_29__ to the __INLINE_CODE_30__-section.

__INLINE_CODE_31__ will automatically load any __INLINE_CODE_32__ and __INLINE_CODE_33__ files, including the default entry point, so you don't have to worry about any rollup configuration.

If you have a __INLINE_CODE_34__ script (normally set to __INLINE_CODE_35__) that will be run as part of the __INLINE_CODE_36__ script (which is run as part of the __INLINE_CODE_37__ script as well).

TypeScript definition files will also automatically be generated during the __INLINE_CODE_38__ script.

Inspiration

This is forked from kcd-scripts.

LICENSE

MIT