Security News
GitHub Removes Malicious Pull Requests Targeting Open Source Repositories
GitHub removed 27 malicious pull requests attempting to inject harmful code across multiple open source repositories, in another round of low-effort attacks.
@productboard/tslint-pb
Advanced tools
These are highly experimental rules we are trying to use in our daily life to help maintain code more effectively. Because the rules are tied to our codebase, it will probably be very difficult to use them in your project. However, you can definitely take
These are highly experimental rules we are trying to use in our daily life to help maintain code more effectively. Because the rules are tied to our codebase, it will probably be very difficult to use them in your project. However, you can definitely take a look! 💪
💡 All the rules consume
reference: string
configuration for custom message
This rule checks if our connect (Flux) or selector implementation has all required dependencies, or if there is some dependency unused. If you are wondering, how this works in real life just ping us – we are hiring. 🤓
{
"rules": {
"check-unused-flux-dependencies": [
true,
{
"reference": "Optional text to explain the error"
}
]
}
}
import { show, hide } from 'selectors/some';
export default compose(connect([show], () => ({
a: show(),
b: hide(),
~~~~ [You forgot to listen for the "hide" dependency!]
})))(component);
💡 This rule has fixer
This rule needs configuration for proper usage. Basically, you are able to set convention on how to group and sort imports based on the naming convention of imports. Check it out tests for the real-case usage.
{
"rules": {
"import-group-order": [
true,
{
"convention": [
"react",
"node_modules",
"libs",
null,
"actions",
"stores",
"selectors",
null,
"components",
null,
"constants",
null,
"styles",
null,
"undefined"
],
"recognizer": {
"react": "^react$",
"node_modules": "^[^/]*$",
"libs": "libs/.*",
"actions": { "regex": "actions?", "flags": "i" },
"stores": { "regex": "stores?", "flags": "i" },
"selectors": { "regex": "selectors?", "flags": "i" },
"components": ["components?/", ".*\\.react$"],
"constants": "constants?.*",
"styles": ".*\\.styles$"
},
"reference": "Optional text to explain the error"
}
]
}
}
import a from "libs/flux/r";
import { b } from "libs/flux/r";
import { c, d, f, g } from "modules/views/libs/v";
import { h } from "stores/u";
import { i } from "constants/b";
import * as j from "constants/b";
import { k, l } from "constants/b";
import { m } from "constants/m";
import { n } from "constants/p";
import { o } from "modules/views/constants/v";
This rule checks if all connect (Flux) or selector dependencies are sorted alphabetically.
{
"rules": {
"sort-flux-dependencies": [
true,
{
"maxLineLength": "For formatting purposes",
"reference": "Optional text to explain the error"
}
]
}
}
connect(
[
AlonglonglongStore,
getLongLongLongA,
~~~~~~~~~~~~~~~~ [Dependency array is not sorted correctly!]
BlonglonglongStore,
getLongLongLongB,
getLongLongLongC,
],
() => {},
)
This rule checks if all AppDispatcher.handleViewAction calls are typed.
{
"rules": {
"flux-action-dispatch": true
}
}
AppDispatcher.handleViewAction({
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
type: 'SIMPLE_ACTION',
~~~~~~~~~~~~~~~~~~~~~~~~
value: 123,
~~~~~~~~~~~~~
});
~~ [handleViewAction must be typed or called with action object containing "type" property only.]
To enforce some rules to our selectors.
Dependency array must be defined as array literal. It's better practice to have the list of dependencies inlined rather than in some variable outside of selector definition.
Dependency array must contain at least one dependency. Otherwise it's probably misused selector and developer should use plain (possibly memoized) function.
Function in selector must be defined as arrow literal.
First for readability we want the function to be inlined and not defined outside of selector definition.
Also, we don't wanna use function
definition, to avoid possible this
abuse.
Default/optional arguments in selector function are forbidden. Unfortunately, JavaScript doesn't play well with default/optional arguments when using memoization on dynamic number of arguments. Therefore we have to disable it to prevent nasty bugs.
This is only forbidden for the default select
with auto-memoization.
All arguments in selector function must be typed.
Unfortunately if you skip types on arguments, it just uses implicit any
(probably because of generics used in select
definition). It's potentially error-prone, so it's good idea to enforce it.
{
"rules": {
"selectors-format": [
true,
{
"importsPaths": {
"select": ["libs/flux", "libs/flux/select"]
},
"reference": "Optional text to explain the error"
}
]
}
}
select(
FLUX_DEPENDENCIES,
~~~~~~~~~~~~~~~~~ [Dependencies must be defined as array literal.]
() => {},
);
select(
[Store],
func,
~~~~ [Function must be defined as arrow function literal.]
);
select(
[Store],
(a: number = 10) => false,
~~~~~~~~~~~~~~ [Default arguments are forbidden.]
);
select(
[Store],
(a?: number) => false,
~~~~~~~~~~ [Optional arguments are forbidden.]
);
select(
[Store],
(abc, xyz) => false,
~~~ [All arguments must be typed.]
~~~ [All arguments must be typed.]
);
Ensure that React is consistently imported without asterisk import.
{
"rules": {
"correct-react-import": true
}
}
import * as React from 'react';
~~~~~~~~~~ [Don't import React with asterisk, use `import React from 'react';`]
import React from 'react';
yarn add -D @productboard/tslint-pb
tslint.json
{
"extends": ["@productboard/tslint-pb"],
"rules": {}
}
There are test provided, just run yarn run test
. For quick prototyping use http://astexplorer.net – it's a great tool! Any contribution welcomed! 🙏
MIT
FAQs
These are highly experimental rules we are trying to use in our daily life to help maintain code more effectively. Because the rules are tied to our codebase, it will probably be very difficult to use them in your project. However, you can definitely take
We found that @productboard/tslint-pb demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 9 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
GitHub removed 27 malicious pull requests attempting to inject harmful code across multiple open source repositories, in another round of low-effort attacks.
Security News
RubyGems.org has added a new "maintainer" role that allows for publishing new versions of gems. This new permission type is aimed at improving security for gem owners and the service overall.
Security News
Node.js will be enforcing stricter semver-major PR policies a month before major releases to enhance stability and ensure reliable release candidates.