
Security News
Vite+ Joins the Push to Consolidate JavaScript Tooling
Evan You announces Vite+, a commercial, Rust-powered toolchain built on the Vite ecosystem to unify JavaScript development and fund open source.
eslint-plugin-no-pipe
Advanced tools
An ESLint plugin to disable the use of the pipe operator.
Examples of incorrect code for this rule:
"Hello, World!" |> console.log(%);
Examples of correct code for this rule:
console.log("Hello, World!");
The pipeline operator currently sits at Stage 2 as an ECMAScript proposal: https://github.com/tc39/proposal-pipeline-operator
While this proposal was started with the best of intentions, the current iteration (also known as the Hack proposal) is a far stretch from what many people had hoped the pipeline operator would bring. In fact, the proposal is so far-stretched that many people (including me) believe it would be better to have no pipeline operator at all, than the one proposed right now.
This lint rule has two purposes:
The pipeline operator is a potentially useful operator that enables functional composition, and can indeed be used to make a series of operations (a pipeline) more readable in code.
Unfortunately, that's not what the Hack proposal is. Instead, the current
proposal is yet another method of doing expression composition. The
difference is that Hack is applicable everywhere in the language where
expressions can be used, which is indeed almost everywhere. Because of this
broad scope, it allows you not only to rewrite console.log("Hello, World!");
as "Hello, World!" |> console.log(%);
, but also a[0]
as a |> %[0]
or
0 |> a[%]
.
Does it matter? As tools such as Prettier have shown, developers like to avoid bikeshedding over style arguments by delegating such choices to tools. And this is great; by forcing a certain amount of uniformity over code, people have fewer issues reading each other's code. Unfortunately, Hack is about to undo this progress by inventing an alternative expression syntax that permeates the entire language.
How do you define which usages of the pipeline operator are sensible, and which are obviously undesirable? With an operator that is restricted to functional composition, this question can be reasonable scoped. But with the Hack proposal, I see no better way to avoid these arguments than to avoid the operator entirely.
Do you want your child to learn to code using "Hello, World!" |> console.log(%);
?
I didn't think so! Please star this repository, and hopefully we can stop the Hack proposal ;)
yarn add -D eslint-plugin-no-pipe
Or:
npm install eslint-plugin-no-pipe --save-dev
Add no-pipe
to the plugins section of your .eslintrc
configuration file. You
can omit the eslint-plugin-
prefix:
{
"plugins": ["no-pipe"]
}
Then add the rule under the rules section:
{
"rules": {
"no-pipe/no-pipe": 2
}
}
FAQs
An ESLint plugin to disable the use of the pipe operator.
We found that eslint-plugin-no-pipe demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer 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
Evan You announces Vite+, a commercial, Rust-powered toolchain built on the Vite ecosystem to unify JavaScript development and fund open source.
Security News
Ruby Central’s incident report on the RubyGems.org access dispute sparks backlash from former maintainers and renewed debate over project governance.
Research
/Security News
Socket researchers uncover how threat actors weaponize Discord across the npm, PyPI, and RubyGems ecosystems to exfiltrate sensitive data.