npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@pkmn/eslint-config

v9.4.0

Published

ESLint configuration from @pkmn based on Pokémon Showdown's style

Downloads

4,010

Readme

@pkmn/eslint-config

License npm version 

ESLint configuration used by @pkmn projects based off of Pokémon Showdown's and Google’s style guidelines:

import pkmn from "@pkmn/eslint-config";

export default pkmn;

NOTE: Due to how ESLint plugins work you must depend on all of the peer dependencies for this package (even if you don't use Typescript or Jest etc).

Ideally this package would extend a @pokemon-showdown/eslint-config and just override the places where it differs (eg. spaces vs. tabs, combining .eslintrc-types.json and .eslintrc-no-types.json into one file). Until then, this package copies Pokémon Showdown's configs and edits are made inline.

Rationale

In general, defer to Pokémon Showdown and Google style guides where it makes sense. However, certain places where @pkmn differs are worth calling out:

null vs. undefined

Use undefined wherever possible. While null is more convenient to type and has better 'semantic' meaning, in an effort to reduce the space of options defaulting to undefined makes more sense:

  • null is easy to avoid in the language whereas undefined shows up far more often (eg. it is the default value for variables, it gets returned by library functions etc)
  • typeof null === 'object' is perhaps useful as it makes sense for an 'empty object reference', but overall seems more likely to cause problems than typeof undefined === 'undefined'
  • foo?: bar notation is TypeScript is more convenient than foo: bar | null (though foo: bar | undefined is relatively obtuse and means something slightly different than foo?: bar)

Note that while undefined is used as the default 'empty' type, all object fields should be initialized in the constructor for performance reasons (the object changing 'shape' or its 'hidden' class as it gains more fields can cause it to become megamorphic).

Tabs vs. Spaces

The same argument about 'removing unnecessary elements' can be applied to justify favoring spaces over tabs - using both is unnecessary, and using spaces for everything (indentation and spacing within a line) is more practical than only using tabs for indenting. Once again, like with null vs undefined where nuanced distinctions exist and its possible to make an argument for preferring one over the other in specific scenarios, its simpler to just say 'only use spaces'.

100-character columns

Google's 80 character column restriction is deemed too draconian and Pokémon Showdown's 120 character limit (which allows beaucoup exceptions via its ignore regex) is seen as too lax and makes it difficult to work on code on smaller displays and still make use of vertical splits.

Quoting

Use ' for everything. In the same way @pkmn tries to use a single bottom type and spacing character, ' is used for everything. ` can and should be used for template strings as opposed to relying on string concatenation, but there's never a need for ".

Enums

Like Pokémon Showdown, @pkmn does not use TypeScript's enum syntax and instead relies on string literal types to represent a restricted range of values. However, unlikely like Pokémon Showdown, @pkmn aims to follow a consistent naming style for the literal constants:

  • Prefer Title Case in almost all cases, and always if it is used to represent a concept which would be be written in Title Case if it appeared in regular text.
  • If the literals are all only single words and would never appear in Title Case, lowercase should be used instead.
  • camelCase can be used if it is required to directly map to keyof some type (ie. to interop with method or field names which do follow camelCase).
  • Never use snake_case or kebab-case.

Legacy string literal types that are required to interface with Pokémon Showdown are of course exempt from these guidelines, but all new string literal types should keep these rules in mind.

Promises

Mishandling of promises can lead to many subtle races and correctness errors. If your code is generating typescript-eslint/no-floating-promises or typescript-eslint/no-misused-promises errors and you don't understand why, please read up on promises or ask for help. Silencing these via // eslint-disable is probably not the correct answer.

Strictness

strict-boolean-expressions and strict-string-expressions should almost certainly be enabled for improved correctness, but @pkmn projects favor terseness and the improved readability that comes with the lax treatment of these cases. This may prove to be a poor tradeoff, but it at least provides encouragement to write tests to mitigate the chances of getting bitten here!

License

This package is distributed under the terms of the MIT License.