1.1.1 • Published 6 years ago

@built/eslint-config v1.1.1

Weekly downloads
-
License
ISC
Repository
bitbucket
Last release
6 years ago

built-eslint

This repository contains the eslint & tslint configurations for our suite of applications. It is meant to be published to npm and registered as a dependency in the apps, modules, and libraries configured to perform "linting" using eslint.

At this time the repository should be published to npm restricted to our scope (@built).

Setup and Local Usage

These are the steps below to get the repo, set it up, and excute the app.

  • Clone the repo with git clone git@bitbucket.org:built/built-eslint.git
  • Change directory to the repo cd built-eslint
  • Ensure that you have latest git pull
  • Install node packages npm install

This will serve to get the repo and install the dependencies. You can now begin creating and/or updating configurations. For new configurations the link below is a valuable reference on how they should be setup.

https://eslint.org/docs/developer-guide/shareable-configs

Notes

  • The repo name and npm package name are different. This is on purpose. The shareable-configs for eslint expect that a configuration follows the pattern of eslint-config*. For the Eslint Shareable configuration,the package name is required to start with eslint-config*. In the case for our use, the individual js files represent the different configurations.
  • If you are making changes and wish to test them in another project locally before publishing (recommended), this can be accomplished in a couple ways, but first a caveat: you may find that this projects dependencies are not installed for you and you may have to temporarily install them to the project you are testing with.
  • Usage of the config has the following in its local .eslintrc and looks like
    {
        "extends": "@built/eslint-config/node-standard"
    }

For the Eslint Shareable configuration, the package name is required to start with eslint-config*. In the case for our use, the individual js files represent the different configurations.

Security

A utility nsp can be used to check that none of the node package dependencies contain known vulnerabilities.

  • npm install -g nsp (or npm update -g nsp if already installed)
  • nsp check

Or to do all of the above in one step: npm run nsp

How to Version & Publish to NPM

The npm cli has a version command that can easily be used to update the package's version # when the package follows semver. For example: running npm version patch would update a package's version in the package.json and committing the change. A package with the version # 1.2.3 would be bumped to 1.2.4. Provide -m 'Some commit message' will add a commit message. npm version minor would bump the minor so the new version would be 1.3.0. There is more that the command can be used for. Most of what it does can be done longhand.

So now that the package has been versioned, we'll want to publish is it. This is done with the npm cli's publish command. In the package.json you'll notice the @built/ prefix on the name attribute. This "scopes" the packages to our private npm repository. By default the publish command will restrict access. npm pack is a way of dry-running the process without actually pushing it to npm. Inclusion of the --tag 0.0.1-rc1 attribute tags the package in a way that we can then install it with npm install @built/built-eslint@0.0.1-rc1. If no tag is specified, the semver version can be used when installing the package. So, an example of the command is: npm publish. If the project is in a different directory, you'll have to specify it: npm publish /Users/foo/project.

Since we largely will utilize a privately scoped repo of packages, you'll most like need to setup authentication to the repo for you shell using npm adduser.

Be very careful publishing packages making sure they are scoped appropriately. Once a package is published with a name and version, that name and version cannot ever be used again. Also, it's iffy about whether or not they will let you remove it at all. If it sits out there for a while and there are dependencies on it, npm may decide to not remove it! http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy.

NPM Scripts

The following npm scripts can be used by running npm run {scriptName} in the command line.

ScriptPurpose
lintRun eslint for the repo
nspRun the security check utility to compare our dependencies against known node vulnerabilities. The script has a pre hook that ensures that nsp is up-to-date
prenspEnsure that nsp is up-to-date. Not really intended to be ran individually, but as a pre condition to nsp
prepublishOnlyNpm script to run prior to publishing to the npm registry.