# @kgrz/tslint-lodash

> TSLint rules for lodash

Latest version **0.0.1-beta.3** (published 2019-07-20) · MIT license · 0 weekly downloads

## Install

```sh
npm install @kgrz/tslint-lodash
pnpm add @kgrz/tslint-lodash
yarn add @kgrz/tslint-lodash
bun add @kgrz/tslint-lodash
```

## Health

**Score 15/100 (F)** — status: abandoned.

Positive: no vulnerabilities.

Warnings: low downloads; no types; no esm support; pre 1.0.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 0.0.1-beta.3 |
| Published | 2019-07-20 |
| First published | 2019-07-20 |
| Weekly downloads | 0 |
| License | MIT |
| TypeScript types | none |
| Module format | CommonJS |
| Dependencies | 0 |
| Unpacked size | 9.7 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| Author | Kashyap Kondamudi |
| Maintainers | kgrz |

## Links

- npm: https://www.npmjs.com/package/@kgrz/tslint-lodash
- Repository: https://github.com/kgrz/tslint-lodash
- Homepage: https://github.com/kgrz/tslint-lodash#readme
- Issues: https://github.com/kgrz/tslint-lodash/issues
- npm.io page: https://npm.io/package/@kgrz/tslint-lodash

## Recent versions

- 0.0.1-beta.3 (latest) — 2019-07-20
- 0.0.1-beta.6 (beta) — 2019-07-31
- 0.0.1-beta.5 — 2019-07-22

## README

TSLint rules for Lodash
-----------------------

⚠️ Disclaimer: These are in no way official TSLint rules for Lodash, and
they do not cover every aspect of the library's usage. Read more about
the motivations below.

🚧 Beta alert! This is sub `0.0.1` release, so buyer beware.

Motivation
----------

`get-check-undefined`:

Due to the changes in how Lodash's TS types (via
[@types/lodash][types-lodash]), and the inherent complexity in defining
good types for `lodash.get` return values, I see the following pattern a
lot in code-reviews:


```javascript
const someObject: string = lodash.get(mainObject, 'some.complicated.path.traversal')
// ...after some more lines of code
const itemLength = someObject.length; // 💥 at runtime, fine at compile time!
```

In most cases, the programmer who wrote this wanted to use `get` just to
have a safe-traversal on a complex object, but didn't bother to add a
default value, perhaps because they were checking for nulls somewhere
down the line.

However, this particular line causes subtle bugs in practice. The
right-side computation can return `undefined` if the path in the object
doesn't exist, even perhaps due to a typo (not all that uncommon). Until
at-least typescript 3.5[breaking-changes], due to the way the
`@types/lodash` types are defined, the return type of `get` when no
default parameter (third argument to the call) is specified is set to
`any`[lodash-type-any]. Due to this, and since we specified the variable
value to be a `string` type, we've potentially masked the case when the
right-side call returns `undefined` <sup>^1</sup>.

It's kind of ironic that without TS, that line would've been checked during
code-reviews thoroughly. Having TS in the codebase kind of gives a sense of
security, and in this case, it ends up providing a false sense of security.

I can't review all the PRs that are opened in our project. So I decided to
automate this.


How it works
------------

🚧 As of `0.0.1.beta.` version, this plugin looks for any function calls
that are `lodash.get` or `get`, and checks the following:

1. Is it being assigned to a variable?
2. If so, does it have `| undefined` in its type definition.

If these two cases match, that line will be marked as an error.


Roadmap
-------

- Add metadata property and specify description
- Add better check for whether the `get` function is actually from lodash. This
  could either be done by providing a configuration option listing out regexes,
  and/or by scanning imports.
- Add tests

Installation
------------

    npm install @kgrz/tslint-lodash@beta

Configuration
-------------

In your project's `tslint.json`, add the following:

```javascript
{
	"extends": [
		"@kgrz/tslint-lodash"
	],
	"rules": {
		"get-check-undefined": true
	}
}
```

-----------


^1: It's kind of interesting to note that in TypeScript 3.5 and above,
these `any` types get auto-converted as `unknown` type, kind of fixing
the problem. `unknown` cannot be converted to a `string`, and will throw
an [error][unknown-gist-link].

[types-lodash]: https://www.npmjs.com/package/@types/lodash
[breaking-changes]: https://devblogs.microsoft.com/typescript/announcing-typescript-3-5#breaking-changes
[lodash-type-any]: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/eff7ed18e676c6b3639c2d8bc30843338ebf49b3/types/lodash/common/object.d.ts#L1787-L1791
[unknown-gist-link]: https://gist.github.com/b9cd1d810c041aeb269593e70e949280

---
_Source: https://npm.io/package/@kgrz/tslint-lodash · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._