@vicinity/eslint-config-vcx
eslintrc as an extensible shared config for vicinity projects
Last updated 9 months ago by rp-vcx .
UNLICENSED · Repository · Bugs · Original npm · Tarball · package.json
$ cnpm install @vicinity/eslint-config-vcx 
SYNC missed versions from official npm registry.

semantic-release Build status

Shared ESlint & TSlint

This repo contains both eslint (index.js) and tslint (tslint.js).

Usage

Add as npm dependency

yarn add @vicinity/eslint-config-vcx -D

NOTE to use private npm registry you have to be logged in with npm login

ESlint

Create an .eslintrc.json file at the root of your project

{
  "extends": "@vicinity/eslint-config-vcx"
}

TSLint

Create an tslint.json file at the root of your project

{
  "extends": "@vicinity/eslint-config-vcx/tslint"
}

Release

To automate the release process and simplify CI, we use the the Angular commit message convention which is also the default commit message convention for semantic-release. Please ensure you follow the guidelines.

How it works?

A new release happens when the master branch builds successfully and there's a formatted commit message that should trigger a semantic version change. A Git tag is created, a GitHub release is created and the package is published to NPM under the new semantic version.

Committing

We use commitlint for commit linting, and husky for Git hooks to prevent bad git commit & git push (specifically, the commit-msg hook.

Take a look at the git history (git log) to get the gist of it.

If you'd like to get some CLI assistance for the commit message format:

npm install
npm run commit

The npm run commit script triggers a helpful commit message CLI (the commitlint cli package)

NOTE: If you're unsure of the options available when running this command you can type in help to see a list of options.

Publishing

The process of creating git tag, updating [CHANGELOG.md, package.json , package-lock.json] and publishing to NPM is fully automated in Buildkite.

For each new commit added to the release branch (master) with git push or by merging a pull request, a CI build is triggered in Buildkite and runs the semantic-release command to make a release if there are codebase changes since the last release that affect the package functionalities.

How to delete a tag

You may need to do this in the case that the release in BuildKite doesn't work or you accidentally create the tag on your local machine

Delete broken tag:

delete local tag 'X.Y.Z'

git tag -d "X.Y.Z"

delete remote tag 'X.Y.Z'

You will only need to run this if the tag created was pushed to the remote repository

git push origin :refs/tags/X.Y.Z

Current Tags

  • 2.1.0                                ...           latest (9 months ago)

17 Versions

  • 2.1.0                                ...           9 months ago
  • 2.0.0                                ...           a year ago
  • 1.4.0                                ...           a year ago
  • 1.3.0                                ...           a year ago
  • 1.2.0                                ...           a year ago
  • 1.1.16                                ...           a year ago
  • 1.1.15                                ...           a year ago
  • 1.1.14                                ...           a year ago
  • 1.1.13                                ...           a year ago
  • 1.1.12                                ...           a year ago
  • 1.1.11                                ...           a year ago
  • 1.1.9                                ...           a year ago
  • 1.1.6                                ...           a year ago
  • 1.1.5                                ...           2 years ago
  • 1.1.4                                ...           2 years ago
  • 1.1.2                                ...           2 years ago
  • 1.1.1                                ...           2 years ago
Downloads
Today 0
This Week 1
This Month 22
Last Day 1
Last Week 18
Last Month 40
Dependents (0)
None

Copyright 2014 - 2016 © taobao.org |