Research
Security News
Quasar RAT Disguised as an npm Package for Detecting Vulnerabilities in Ethereum Smart Contracts
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
@blueprintjs/eslint-plugin
Advanced tools
Blueprint is a React UI toolkit for the web.
This package contains the ESLint plugin for Blueprint. It provides custom rules which are useful when developing against Blueprint libraries.
Key features:
@blueprintjs
components.yarn add --dev @blueprintjs/eslint-plugin
Add the "@blueprintjs"
plugin to your ESLint config:
{
"plugins": ["@blueprintjs"]
}
To enable all rules provided by the plugin the Blueprint-specific rules, extend the plugin:@blueprintjs/recommended
configuration:
{
"extends": ["plugin:@blueprintjs/recommended"]
}
Alternatively, you may enable specific rules provided the plugin:
{
"rules": {
"@blueprintjs/classes-constants"
"@blueprintjs/no-deprecated-components": "error"
}
}
@blueprintjs/classes-constants
Enforce usage of class names exported as public API via the Classes
object instead of string literals like "bp5-dark"
.
Each @blueprintjs
package exports a Classes
object which contains constants for every CSS class defined by the package.
Rationale: This is useful to avoid typos in styling or creating Blueprint components, and also helps future-proof your code for major
version bumps of Blueprint where the class namespace (e.g. bp5-
) changes.
{
"rules": {
"@blueprintjs/classes-constants": "error"
}
}
Has auto-fixer: ✅
- const element = <div className="pt-navbar" />;
+ const element = <div className={Classes.NAVBAR} />;
@blueprintjs/html-components
Enforce usage of Blueprint components over regular HTML JSX tags:
Rationale: This is uesful to ensure consistent styling of common typographic elements and other basic markup.
Has auto-fixer: ✅
{
"rules": {
"@blueprintjs/html-components": ["error"]
}
}
@blueprintjs/icon-components
:warning: DEPRECATED: this rule is no longer recommended. Icons modularity / tree shaking is a first-class feature of Blueprint v5.x.
Enforce usage of JSX Icon
components instead of IconName
string literals (or vice-versa) in icon
JSX props.
Note that this rule only supports hardcoded values in the icon
prop; it does not handle expressions or conditionals.
A fixer is available for this rule that will convert between string literals and named Icon
components. Note that the implementation is naive and may require intervention, such as to import a component or fix an invalid name.
Named icon components (Tick
, Graph
, etc) can be imported from the @blueprintjs/icons
package.
This rule is disabled in the blueprint-rules
config as it is most useful to ensure that the @blueprintjs/icons
package can be tree-shaken (an opt-in process which requires using components and never IconName
literals).
{
"rules": {
// default uses "component"
"@blueprintjs/icon-components"
// expanded syntax
"@blueprintjs/icon-components": ["error", "component" | "literal"] // choose one
}
}
"component"
-<Button icon="tick" />
+<Button icon={<TickIcon />} />
"literal"
-<Button icon={<GraphIcon />} />
+<Button icon="graph" />
@blueprintjs/no-deprecated-components
Ban usage of deprecated components in the current major version of all Blueprint packages, including:
Rationale: There are two reasons why a particular component may be deprecated:
Many Blueprint components have next-generation variants as a part of their natural API evolution. Blueprint
consumers are recommended to migrate from the deprecated "V1" components to their newer V2 counterparts
in order to future-proof their code for the next major version of Blueprint, where the V2 components will become
the only available API and the "V1" variants will be removed. Flagging usage of deprecated APIs can be done with
other ESLint rules like deprecation/deprecation
, but that rule is often too broad to enable as an "error"
globally across a large code base. @blueprintjs/no-deprecated-components
provides a simpler, more scoped rule
which only flags usage of deprecated Blueprint components in JSX syntax. The idea here is that you can enable this
rule as an "error" in ESLint to prevent any backwards progress in your Blueprint migration as you migrate to newer
APIs in preparation for the next major version.
When a next-generation component API (designated as "V2" or "V3") is "promoted" to the standard "V1" API in a
major version of Blueprint, we keep around aliases for the "V2" names which referred to that same API in the
previous major version. These names are immediately marked as /** @deprecated */
and you are encouraged to
migrate to their corresponding "V1" symbols after a major upgrade. For example,
{ Popover2 } from "@blueprintjs/popover2"
is the recommended popover API in Blueprint v4.x, but it is deprecated
in Blueprint v5.x. If you continue to use Popover2
in v5.x, you will get a lint error suggesting a rename
migration to { Popover } from "@blueprintjs/core"
. Since these symbols are aliases for each other in v5.x, there
should be no runtime impact from this kind of migration.
@blueprintjs/no-deprecated-core-components
Similar to @blueprintjs/no-deprecated-components
, but only flags usage of deprecated components from the
@blueprintjs/core
package instead of all @blueprintjs/
packages.
Rationale: In migrations of large code bases, it may be useful to apply more granular rule configuration of
"no-deprecated-components" to make incremental progress towards the newer APIs. This allows you, for example, to flag
deprecated @blueprintjs/core
component usage as errors while allowing deprecated components from other packages
to pass as lint warnings.
@blueprintjs/no-deprecated-datetime-components
Similar to @blueprintjs/no-deprecated-components
, but only flags usage of deprecated components from the
@blueprintjs/datetime
package instead of all @blueprintjs/
packages.
Rationale: In migrations of large code bases, it may be useful to apply more granular rule configuration of
"no-deprecated-components" to make incremental progress towards the newer APIs. This allows you, for example, to flag
deprecated @blueprintjs/datetime
component usage as errors while allowing deprecated components from other packages
to pass as lint warnings.
@blueprintjs/no-deprecated-datetime2-components
Similar to @blueprintjs/no-deprecated-components
, but only flags usage of deprecated components from the
@blueprintjs/datetime2
package instead of all @blueprintjs/
packages.
Rationale: In migrations of large code bases, it may be useful to apply more granular rule configuration of
"no-deprecated-components" to make incremental progress towards the newer APIs. This allows you, for example, to flag
deprecated @blueprintjs/datetime2
component usage as errors while allowing deprecated components from other packages
to pass as lint warnings.
@blueprintjs/no-deprecated-popover2-components
Similar to @blueprintjs/no-deprecated-components
, but only flags usage of deprecated components from the
@blueprintjs/popover2
package instead of all @blueprintjs/
packages.
Rationale: In migrations of large code bases, it may be useful to apply more granular rule configuration of
"no-deprecated-components" to make incremental progress towards the newer APIs. This allows you, for example, to flag
deprecated @blueprintjs/popover2
component usage as errors while allowing deprecated components from other packages
to pass as lint warnings.
@blueprintjs/no-deprecated-select-components
Similar to @blueprintjs/no-deprecated-components
, but only flags usage of deprecated components from the
@blueprintjs/select
package instead of all @blueprintjs/
packages.
Rationale: In migrations of large code bases, it may be useful to apply more granular rule configuration of
"no-deprecated-components" to make incremental progress towards the newer APIs. This allows you, for example, to flag
deprecated @blueprintjs/select
component usage as errors while allowing deprecated components from other packages
to pass as lint warnings.
@blueprintjs/no-deprecated-table-components
Similar to @blueprintjs/no-deprecated-components
, but only flags usage of deprecated components from the
@blueprintjs/table
package instead of all @blueprintjs/
packages.
Rationale: In migrations of large code bases, it may be useful to apply more granular rule configuration of
"no-deprecated-components" to make incremental progress towards the newer APIs. This allows you, for example, to flag
deprecated @blueprintjs/table
component usage as errors while allowing deprecated components from other packages
to pass as lint warnings.
@blueprintjs/no-deprecated-type-references
Ban usage of deprecated types & interfaces. In most cases, these symbols are deprecated as a result of our new
TypeScript interface naming convention where we've dropped the "I" prefix from interface names. For example,
IProps
is now Props
.
Auto-fixable.
Rationale: Ensure forwards-comaptibility with the next major version of Blueprint and use the auto-fixer as a codemod.
FAQs
ESLint rules for use with @blueprintjs packages
We found that @blueprintjs/eslint-plugin demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 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.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.