Tuesday, 1 January 2019

How to install Go on Ubuntu 18.04

Download archive for Ubuntu from golang's Download page and unpack it into /usr/local:

$ tar -C /usr/local -xzf go1.11.4.linux-amd64.tar.gz



This creates /usr/local/go installation directory which contains binaries in /usr/local/go/bin. This path, together with the path to your Go workspace directory (unless it's placed at its default location $HOME/go) shall be added to bash configuration so it's accessible from terminal. Open the configuration:

$ sudo gedit ~/.bashrc

and add:

export PATH=$PATH:/usr/local/go/bin
export GOPATH=$HOME/dev/go

To test the installation, please find the procedure in How to install Go on Nvidia Jetson TX2 article.

Wednesday, 26 December 2018

How to install Gimp on Ubuntu 18.06

$ sudo add-apt-repository ppa:otto-kesselgulasch/gimp
$ sudo apt-get update
$ sudo apt-get install gimp

How to install Go on Nvidia Jetson TX2

Downloads page on Go's website lists archives and installers for all major operating systems and architectures. Jetson TX runs custom version of Ubuntu called Linux for Tegra (L4T):

$ uname -a
Linux tegra-ubuntu 4.4.38-tegra #1 SMP PREEMPT Thu May 17 00:15:19 PDT 2018 aarch64 aarch64 aarch64 GNU/Linux




To find the processor architecture we can check out the content of /proc/cpuinfo file:

$ cat /proc/cpuinfo

processor : 0
model name : ARMv8 Processor rev 3 (v8l)
BogoMIPS : 62.50
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 3

processor : 3
model name : ARMv8 Processor rev 3 (v8l)
BogoMIPS : 62.50
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 3

processor : 4
model name : ARMv8 Processor rev 3 (v8l)
BogoMIPS : 62.50
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 3

processor : 5
model name : ARMv8 Processor rev 3 (v8l)
BogoMIPS : 62.50
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 3


We can see that Jetson TX2 uses version 8 of the ARM instruction set. Luckily, Go Downloads page provides archive for ARMv8 (Downloads >> Stable Versions >> Other Ports). At the time of writing the latest version was:

go1.11.4.linux-arm64.tar.gz Archive Linux ARMv8 96MB


Upon downloading the archive and verifying its checksum we can install Go by extracting it into /usr/local directory:

tar -C /usr/local -xzf go1.11.4.linux-arm64.tar.gz


Go binaries are in /usr/local/go/bin directory and to make them available from any new terminal session we have to add and persist this path to PATH environment variable.

We have to edit bash configuration:

$ sudo gedit ~/.bashrc

...by appending go bin path to PATH:

export PATH=(...):/usr/local/go/bin


Go installation requires defining which local directory will be Go workspace (place with all Go repositories - source code, builds and packages). I chose it to be dev/go directory in my home directory instead of the default one which is $HOME/go. For I am using non-default workspace location I have to add another environment variable in the same bash config file:

export GOPATH=$HOME/dev/go


As I've already created Go test project on my GitHub account when I was testing Go installation on Windows we can simply clone that project. Before we do it, let's make go get use SSH URL instead of HTTPS so we don't have to change it later manually (like on Windows). To achieve this we have to change global git configuration (suggested here):

$ git config --global url.git@github.com:.insteadOf https://github.com/


Let's do the clone now:

~/dev/go$ mkdir src
~/dev/go$ cd src
~/dev/go/src$ go get github.com/BojanKomazec/go-hello-world




We now have a sample go file: ~/dev/go/src/github.com/BojanKomazec/go-hello-world/hello/hello.go.

To verify that SSH URL has been used we can execute:

~/dev/go/src/github.com/BojanKomazec/go-hello-world$ git remote get-url origin
git@github.com:BojanKomazec/go-hello-world


Let's go to hello directory and build our go file:

$ go build hello.go


This creates hello executable that we can run:

$ ./hello
hello, world


This proves that our Go installation on Jetson TX2 was successful.

Saturday, 22 December 2018

Setting up Go on Windows

Go (Golang) is installed on Windows via its msi installer available on Go's website. The latest version at the time of writing this article was 1.11.4 and the installer go1.11.4.windows-amd64.msi.



Installation is straightforward:







By default, installer creates or modifies the following environment variables:

In System space:

   Variable (created): GOROOT
   Value: C:\Go\
   Description: Go installation location.

   Variable (value appended): Path
   Value: C:\Go\bin
   Description: Go binaries location.


In User space:

   Variable (created): GOPATH
   Value: %USERPROFILE%\go
   Description: User's go workspace path.

   Variable (value appended): Path
   Value: %USERPROFILE%\go\bin
   Description: User's Go applications' binaries location.


Go workspace:
  • a directory with two subdirectories: bin and src
    • src typically contains all repositories with Go projects
    • bin contains built and then installed Go application binaries
  • can be set at arbitrary location; I set mine to C:\dev\go (and also set User space Path to C:\dev\go\bin)

Upon installation, C:\Go\bin contains three binaries:
  • go -  Tool for managing Go source code
  • godoc - Documentation tool; parses Go source code - including comments - and produces documentation as HTML or plain text
  • gofmt - Go source code formatter; uses tabs for indentation and blanks for alignment. 



Let's see what are the command line arguments of go tool:

>go
Go is a tool for managing Go source code.

Usage:

        go <command> [arguments]

The commands are:

        bug         start a bug report
        build       compile packages and dependencies
        clean       remove object files and cached files
        doc         show documentation for package or symbol
        env         print Go environment information
        fix         update packages to use new APIs
        fmt         gofmt (reformat) package sources
        generate    generate Go files by processing source
        get         download and install packages and dependencies
        install     compile and install packages and dependencies
        list        list packages or modules
        mod         module maintenance
        run         compile and run Go program
        test        test packages
        tool        run specified go tool
        version     print Go version
        vet         report likely mistakes in packages

Use "go help <command>" for more information about a command.

Additional help topics:

        buildmode   build modes
        c           calling between Go and C
        cache       build and test caching
        environment environment variables
        filetype    file types
        go.mod      the go.mod file
        gopath      GOPATH environment variable
        gopath-get  legacy GOPATH go get
        goproxy     module proxy protocol
        importpath  import path syntax
        modules     modules, module versions, and more
        module-get  module-aware go get
        packages    package lists and patterns
        testflag    testing flags
        testfunc    testing functions





If we already have some Go project in some Git repository (like GitHub), we can use get command to clone the given repository:

C:\dev\go\src>go get github.com/BojanKomazec/go-hello-world
package github.com/BojanKomazec/go-hello-world: no Go files in
C:\dev\go\src\github.com\BojanKomazec\go-hello-world

Repository is cloned to C:\dev\go\src\github.com\BojanKomazec\go-hello-world directory.

Repository shall be written without starting https:// as go get would report an error:

C:\dev\go\src>go get https://github.com/BojanKomazec/go-hello-world
package https:/github.com/BojanKomazec/go-hello-world: https:/github.com/BojanKomazec/go-hello-world: invalid import path: malformed import path "https:/github.com/BojanKomazec/go-hello-world": invalid char ':'

This my repository only has .gitignore and README.md files so let's add some code. First, let's create a directory named hello and in it a go file with the following content:

C:\dev\go\src\github.com\BojanKomazec\go-hello-world\hello\hello.go:

package main

import "fmt"

func main() {
   fmt.Printf("hello, world\n")
}


Building this file with:

C:\dev\go\src\github.com\BojanKomazec\go-hello-world\hello>go build

...creates a hello.exe file in the same directory and we can run it:

C:\dev\go\src\github.com\BojanKomazec\go-hello-world\hello>hello
hello, world

To install that build as a package, we have to run:

C:\dev\go\src\github.com\BojanKomazec\go-hello-world\hello>go install

This deploys application binary in C:\dev\go\bin directory.

go tool and Git

If we add, commit and then try to push hello.go file to remote repository, we'll be prompted by Git to enter our GitHub credentials as by default go get sets the https-based URL of the remote. We can verify that with:

C:\dev\go\src\github.com\BojanKomazec\go-hello-world>git remote show origin
* remote origin
  Fetch URL: https://github.com/BojanKomazec/go-hello-world
  Push  URL: https://github.com/BojanKomazec/go-hello-world
  HEAD branch: master
  Remote branch:
    master tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

We can set SSH-based URL by executing:

>git remote set-url origin git@github.com:BojanKomazec/go-hello-world.git

Let's verify it:

C:\dev\go\src\github.com\BojanKomazec\go-hello-world>git remote show origin
Enter passphrase for key '/c/Users/komazec/.ssh/id_rsa':
* remote origin
  Fetch URL: git@github.com:BojanKomazec/go-hello-world.git
  Push  URL: git@github.com:BojanKomazec/go-hello-world.git
  HEAD branch: master
  Remote branch:
    master tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

Let's now analyse code in the go source file above.

package main

func main() {
   ...
}


This line tells the Go compiler that the package should compile as an executable program. Its entry point will be function main(). If we were building a shared library, we would use package lib directive and there would not be main() function in the package.

import "fmt"
...
fmt.Printf("hello, world\n")

import statement imports a package into other package. Here, we wanted to use function which prints a string onto standard output. Such function, Printf, is available in the fmt package which comes from the Go standard library. Go compiler looks for standard library packages on paths specified in GOROOT and your and third-party packages on path specified in GOPATH environment variables.

Project on GutHub:

https://github.com/BojanKomazec/go-hello-world

References:

golang.org: Go installation on Windows
Understanding Golang Packages
Package “main” and func “main”

Tuesday, 11 December 2018

Introduction to Yarn

Yarn
  • package manager
  • developed by Facebook
  • uses the same package.json as npm
  • uses its own lock file - yarn.lock (not package-lock.json like npm)
  • if installing it on Windows via installer, Node.js has to be installed first
  • once installed re-launch terminal and type yarn -v to verify that it's installed successfully and see its version
  • if you check out some project which uses yarn, you would typically first run yarn install to install all the dependencies of project
  • each module has npm-based and yarn-based packages so can be installed via either dependency manager. E.g. babel-core:
    • npm: npm install --save-dev @babel/core
    • yarn: yarn add @babel/core --dev

Sunday, 9 December 2018

How to install JetPack 3.3 on Ubuntu 18.04 and flash Jetson TX2

In July this year NVIDIA released JetPack 3.3 - currently the latest stable/production version of JetPack. Some of its features are:
This is the last JetPack that will be supporting Jetson TX2 and TX1 Developer Kits. JetPack 4.1.1 Developer Preview supports only new Jetson AGX Xavier Developer Kit but it will not be supporting TX2 or TX1).


Although official release notes for JetPack 3.3 state that supported Ubuntu on the host is 16.04, I had no issues installing this version of JetPack (and later flashing TX2) on my Ubuntu 18.04 with details:

~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic

I downloaded JetPack-L4T-3.3-linux-x64_b39.run from NVIDIA Developer Center, added execution permission and ran it as non-admin (installer prompts user for elevated privilege only when necessary). If you run it as super user, installer will show you an error: 


Installer unpacks its content into a directory whcih has the following content: 

~/Downloads/JetPack$ ls
64_TX2
devtools_docs
_installer
jetpack_docs
jetpack_download
JetPack-L4T-3.3-linux-x64_b39.run
JetPack_Uninstaller
NVIDIA_System_Profiler
nvl4t_docs
README.txt
Start_L4T_Docs.html
Tegra_Linux_Driver_Package_Release_Notes_R28.2.1.pdf

Although I got the following message as was running the installer on Ubuntu 18.04, I clicked "Yes" and had no issues during the process:


These are the screenshots of the successful JetPack 3.3 installation on Ubuntu 18.04 and flashing Jetson TX2:





It takes couple of seconds for Component Manager to download repo information, do version checks and show the current state of packages:












At this point I actually stopped the installation as wanted to do flashing of TX a bit later. This is possible as Component Manager will pick up and show the current state of all packages upon JetPack installer re-launch:











Now I pressed ENTER to resume the installation.








Just like before, I verified that all has completed successfully on TX2 by running some of installed CUDA demo examples (e.g. rendering ocean surface - "OceanFFT"). 

Thursday, 11 October 2018

Introduction to TSLint

TSLint is a TypeScript linter.

Source code of the project which uses TSLint is on GitHub.

Installation

Let's install it as a development dependency:

..\demo-typescript>npm install tslint --save-dev
+ tslint@5.11.0
added 40 packages from 20 contributors and audited 51 packages in 5.225s
found 0 vulnerabilities

CLI Usage

Let's run tslint with no arguments specified, from the project's root directory:

..\demo-typescript>npx tslint
No files specified. Use --project to lint a project folder.

Let's find what is --project argument and see what are the other command line arguments:

..\demo-typescript>npx tslint --help
Usage:  [options]

Options:
  -v, --version                          output the version number
  -c, --config [config]                  configuration file
  -e, --exclude <exclude>                exclude globs from path expansion (default: [])
  --fix                                  fixes linting errors for select rules (this may overwrite linted files)
  --force                                return status code 0 even if there are lint errors
  -i, --init                             generate a tslint.json config file in the current working directory
  -o, --out [out]                        output file
  --outputAbsolutePaths                  whether or not outputted file paths are absolute
  -r, --rules-dir [rules-dir]            rules directory
  -s, --formatters-dir [formatters-dir]  formatters directory
  -t, --format [format]                  output format (prose, json, stylish, verbose, pmd, msbuild, checkstyle, vso, fileslist, codeFrame)
  --test                                 test that tslint produces the correct output for the specified directory
  -p, --project [project]                tsconfig.json file
  --type-check                           (deprecated) check for type errors before linting the project
  -h, --help                             output usage information
tslint accepts the following commandline options:

    -c, --config:
        The location of the configuration file that tslint will use to
        determine which rules are activated and what options to provide
        to the rules. If no option is specified, the config file named
        tslint.json is used, so long as it exists in the path.
        The format of the file is { rules: { /* rules list */ } },
        where /* rules list */ is a key: value comma-separated list of
        rulename: rule-options pairs. Rule-options can be either a
        boolean true/false value denoting whether the rule is used or not,
        or a list [boolean, ...] where the boolean provides the same role
        as in the non-list case, and the rest of the list are options passed
        to the rule that will determine what it checks for (such as number
        of characters for the max-line-length rule, or what functions to ban
        for the ban rule).

    -e, --exclude:
        A filename or glob which indicates files to exclude from linting.
        This option can be supplied multiple times if you need multiple
        globs to indicate which files to exclude.

    --fix:
        Fixes linting errors for select rules. This may overwrite linted files.

    --force:
        Return status code 0 even if there are any lint errors.
        Useful while running as npm script.

    -i, --init:
        Generates a tslint.json config file in the current working directory.

    -o, --out:
        A filename to output the results to. By default, tslint outputs to
        stdout, which is usually the console where you're running it from.

    --outputAbsolutePaths:
        If true, all paths in the output will be absolute.

    -r, --rules-dir:
        An additional rules directory, for user-created rules.
        tslint will always check its default rules directory, in
        node_modules/tslint/lib/rules, before checking the user-provided
        rules directory, so rules in the user-provided rules directory
        with the same name as the base rules will not be loaded.

    -s, --formatters-dir:
        An additional formatters directory, for user-created formatters.
        Formatters are files that will format the tslint output, before
        writing it to stdout or the file passed in --out. The default
        directory, node_modules/tslint/build/formatters, will always be
        checked first, so user-created formatters with the same names
        as the base formatters will not be loaded.

    -t, --format:
        The formatter to use to format the results of the linter before
        outputting it to stdout or the file passed in --out. The core
        formatters are prose (human readable), json (machine readable)
        and verbose. prose is the default if this option is not used.
        Other built-in options include pmd, msbuild, checkstyle, and vso.
        Additional formatters can be added and used if the --formatters-dir
        option is set.

    --test:
        Runs tslint on matched directories and checks if tslint outputs
        match the expected output in .lint files. Automatically loads the
        tslint.json files in the directories as the configuration file for
        the tests. See the full tslint documentation for more details on how
        this can be used to test custom rules.

    -p, --project:
        The path to the tsconfig.json file or to the directory containing
        the tsconfig.json file. The file will be used to determine which
        files will be linted. This flag also enables rules that require the
        type checker.

    --type-check:
        (deprecated) Checks for type errors before linting a project.
        --project must be specified in order to enable type checking.

    -v, --version:
        The current version of tslint.

    -h, --help:
        Prints this help message.

Let's specify path to tsconfig.json file (which is in the project's root where we're executing tsling from):

..\demo-typescript>npx tslint --project ./
no-unused-variable is deprecated. Since TypeScript 2.9. Please use the built-in compiler checks instead.

Could not find implementations for the following rules specified in the configuration:
    label-undefined
    no-duplicate-key
    no-trailing-comma
    no-unreachable
    use-strict
Try upgrading TSLint and/or ensuring that you have all necessary custom rules installed.
If TSLint was recently upgraded, you may have old rules configured which need to be cleaned up.


ERROR: C:/dev/github/demo-typescript/src/index.ts[3, 5]: expected variable-declaration: 'dayTimeGreetingGenerator' to have a typedef
ERROR: C:/dev/github/demo-typescript/src/index.ts[5, 10]: expected call-signature: 'createPersonalGreeting' to have a typedef
ERROR: C:/dev/github/demo-typescript/src/index.ts[9, 5]: expected variable-declaration: 'user' to have a typedef
ERROR: C:/dev/github/demo-typescript/src/index.ts[12, 5]: expected variable-declaration: 'greeting' to have a typedef
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[2, 19]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[3, 21]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[4, 19]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[1, 57]: trailing whitespace
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[5, 25]: expected nospace before colon in call-signature
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[7, 33]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/greetingGenerator.ts[1, 18]: interface name must start with a capitalized I
ERROR: C:/dev/github/demo-typescript/src/module/greetingGenerator.ts[2, 18]: expected nospace before colon in call-signature

Good, linting works!

Configuration


If we run:

..\demo-typescript>npx tslint --init

...tslint creates TSLint configuration file - tslint.json in the current directory.  tslint.json for now only has its default content:

{
    "defaultSeverity": "error",
    "extends": [
        "tslint:recommended"
    ],
    "jsRules": {},
    "rules": {},
    "rulesDirectory": []
}

After having TSLint config file, its output contains only linting messages:

..\demo-typescript>npx tslint --project ./

ERROR: C:/dev/github/demo-typescript/src/index.ts[3, 5]: Identifier 'dayTimeGreetingGenerator' is never reassigned; use 'const' instead of 'let'.
ERROR: C:/dev/github/demo-typescript/src/index.ts[5, 39]: expected nospace before colon in parameter
ERROR: C:/dev/github/demo-typescript/src/index.ts[9, 5]: Identifier 'user' is never reassigned; use 'const' instead of 'let'.
ERROR: C:/dev/github/demo-typescript/src/index.ts[12, 5]: Identifier 'greeting' is never reassigned; use 'const' instead of 'let'.
ERROR: C:/dev/github/demo-typescript/src/index.ts[14, 1]: Calls to 'console.log' are not allowed.
ERROR: C:/dev/github/demo-typescript/src/index.ts[14, 23]: file should end with a newline
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[2, 19]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[3, 21]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[4, 19]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[4, 33]: Missing trailing comma
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[5, 2]: file should end with a newline
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[1, 57]: trailing whitespace
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[2, 1]: Import sources within a group must be alphabetized.
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[5, 25]: expected nospace before colon in call-signature
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[6, 20]: expected nospace before colon in variable-declaration
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[7, 21]: expected nospace before colon in variable-declaration
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[7, 33]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[8, 21]: missing whitespace
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[17, 3]: file should end with a newline
ERROR: C:/dev/github/demo-typescript/src/module/greetingGenerator.ts[1, 18]: interface name must start with a capitalized I
ERROR: C:/dev/github/demo-typescript/src/module/greetingGenerator.ts[2, 18]: expected nospace before colon in call-signature
ERROR: C:/dev/github/demo-typescript/src/module/greetingGenerator.ts[3, 2]: file should end with a newline


We can now add linting to TS build task in package.json. TSLint documentation says "Please ensure that the TypeScript source files compile correctly before running the linter." and we'll place linting after transpilation:

"build-ts": "tsc && tslint -p ./",

If we run npm task we'll see that TSLint process exited with error code:

..\demo-typescript>npm run build-ts

> demo-typescript@1.0.0 build-ts C:\dev\github\demo-typescript
> tsc && tslint -p ./


ERROR: C:/dev/github/demo-typescript/src/index.ts[3, 5]: Identifier 'dayTimeGreetingGenerator' is never reassigned; use 'const' instead of 'let'.
ERROR: C:/dev/github/demo-typescript/src/index.ts[5, 39]: expected nospace before colon in parameter
ERROR: C:/dev/github/demo-typescript/src/index.ts[9, 5]: Identifier 'user' is never reassigned; use 'const' instead of 'let'.
ERROR: C:/dev/github/demo-typescript/src/index.ts[12, 5]: Identifier 'greeting' is never reassigned; use 'const' instead of 'let'.
ERROR: C:/dev/github/demo-typescript/src/index.ts[14, 1]: Calls to 'console.log' are not allowed.
ERROR: C:/dev/github/demo-typescript/src/index.ts[14, 23]: file should end with a newline
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[2, 19]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[3, 21]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[4, 19]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[4, 33]: Missing trailing comma
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreeting.ts[5, 2]: file should end with a newline
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[1, 57]: trailing whitespace
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[2, 1]: Import sources within a group must be alphabetized.
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[5, 25]: expected nospace before colon in call-signature
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[6, 20]: expected nospace before colon in variable-declaration
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[7, 21]: expected nospace before colon in variable-declaration
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[7, 33]: ' should be "
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[8, 21]: missing whitespace
ERROR: C:/dev/github/demo-typescript/src/module/dayTimeGreetingGenerator.ts[17, 3]: file should end with a newline
ERROR: C:/dev/github/demo-typescript/src/module/greetingGenerator.ts[1, 18]: interface name must start with a capitalized I
ERROR: C:/dev/github/demo-typescript/src/module/greetingGenerator.ts[2, 18]: expected nospace before colon in call-signature
ERROR: C:/dev/github/demo-typescript/src/module/greetingGenerator.ts[3, 2]: file should end with a newline

npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! demo-typescript@1.0.0 build-ts: `tsc && tslint -p ./`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the demo-typescript@1.0.0 build-ts script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\komazec\AppData\Roaming\npm-cache\_logs\2018-10-11T16_35_49_031Z-debug.log

Having TSLint exit with Exit status 2 is expected as TSLint reported suggestions with ERROR severity and its documentation says that status 2 indeed means "Linting failed with one or more rule violations with severity error".

We can see that linter complaints about using single quotation marks instead of double ones (' should be "). TS coding conventions actually prefers single quotes so we want to change the rule for TSLinter. The rule we want to change in tslint.json is quotemark:

    ...
    "rules": {
        "quotemark": [true, "single"]
    },
    ...

If we run tslint again, we'll see that it does not emit ' should be " messages anymore.

VSCode Extension

TSLint

It will start showing errors/suggestions as soon as plugin is installed and VSCode reloaded.

References:


https://palantir.github.io/tslint/
tslint says calls to console.log are not allowed - How do I allow this?