Skip to content

Latest commit

 

History

History
68 lines (43 loc) · 4.31 KB

JsTargets.md

File metadata and controls

68 lines (43 loc) · 4.31 KB
Raw

JS targets (ESLint) Gulp task

This helper makes it possible to copy one or multiple javascript files to a destination folder, after applying linting (with ESLint) on it.

Looking for something similar for .NET? Check out our .NET Analyzers project.

You can use ESLint as follows:

  1. Copy example.eslintrc from the ESLint folder of this project to the root folder of your solution (i.e. where you have the sln file), rename it to .eslintrc, and specify lombiq-base.js's location inside.

  2. Import the Tasks/js-targets.js file in your Gulpfile then create a Gulp task that uses this helper as a pipeline.

  3. If you use Visual Studio's built-in ESLint, it will recognize the rules and show any violations after the copying of .eslintrc as mentioned above. Note that you have to enable the ESLint integration for it to work in the editor. The vs-eslint-package.json file is automatically copied into your solution directory as package.json to make this work; gitignore it in your repository along the lines of:

    /src/package.json

Configuring the Gulp task

The input parameters are strings of the source and destination folders containing scripts that need to be analyzed and copied.

Usage:

const jsTargets = require('path/to/Lombiq.Gulp.Extensions/Tasks/js-targets');

const source = './Assets/Scripts/'
const destination = './wwwroot/js'

gulp.task('build:scripts', () => jsTargets.compile(source, destination));

// Or you can pass a function to modify the pipeline before saving the files and e.g. run Babel:
gulp.task(
    'build:scripts',
    () => jsTargets.compile(source, destination, (pipeline) => pipeline.pipe(babel({ presets: ['@babel/preset-env'] }))));

// You can also pass additional options to ESLint.
// Here's an example for fixing automatically fixable rule violations in-place:
gulp.task(
    'build:scripts--fix',
    () => jsTargets.compile(scriptsBasePath, scriptsBasePath, null, { fix: true }));

Read more about options in the CLI documentation.

ESlint rules

The rules are found in 2 files:

  • lombiq-base.js: These rules are Lombiq overrides for the extended Airbnb rules.
  • .eslintrc: In this file you can define your own overriding rules.

Details on rules can be found in the ESLint documentation.

The MSBuild output or the Gulp task runner will show you all of the ESLint rule violations in a detailed manner.

If a certain rule's violation is incorrect in a given location, or you want to suppress it locally, you can disable them. Just always comment such disables so it's apparent why it was necessary.

Operating System Compatibility Regarding Git and Line Breaks

For historical reasons, Windows uses the \r\n character combination (also known as CR-LF) to denote a line break, while Unix-like operating systems such as Linux and macOS simply use a single \n character (LF). Git (made by the creator of Linux) treats the Unix-style line endings as the only right option. If you are on Windows your Git client is almost certainly configured to "Checkout Windows-style, commit Unix-style" by default to overcome this cultural difference, but if not then it's a good practice to configure Git to ensure your line endings are consistent. We've disabled the linebreak-style rule to avoid cross compatibility issues.

To ensure that the files have consistent line endings in the remote repository, you can add the following .gitattributes file:

* text=auto

This will enforce the aforementioned Git configuration on a per-repository basis. The files will be checked out using your operating system's native line endings but will be committed using the Unix-style line endings. Note that the conversion only happens once you add your files to the staged changes.