DEV Community: Ken Okabe

All-in-One GitHub Repository-Driven Dev.to Article Management System

Ken Okabe — Thu, 08 May 2025 04:01:35 +0000

https://github.com/ken-okabe/devto-article-cli-private

All-in-One GitHub Repository-Driven Dev.to Article Management System

Welcome to devto-article-cli!

This repository is designed to be your central hub for managing Dev.to articles.

It not only contains the Node.js command-line tool itself but also serves as the primary storage and version control system for your article content (typically within the articles/ directory). The included CLI scripts empower you to seamlessly create, edit (in Markdown), version with Git, and publish your Dev.to articles directly from this integrated, local-first environment.

This README is also intended to be interpretable by AI agents (e.g., GitHub Copilot, VSCode AI assistants) to facilitate their use of this tool.

Features

Write articles locally and use Git for version control.
Publish new articles and update existing ones on Dev.to with simple commands.
Automatically appends Dev.to article ID to Markdown files upon publishing.
Automatic Image Handling: Converts local relative image paths in your Markdown to absolute GitHub URLs when publishing to Dev.to, while keeping your local files unchanged for easy previewing.
Check consistency between local articles and Dev.to.
No CI needed; everything is handled in your local environment.
Fully automates git add, git commit, and git push for the publishing workflow.
Compliant with the latest Forem API V1 (1.0.0).

Prerequisites (For Users and AI Agents)

Node.js (LTS recommended)
Git
Dev.to account and API Key

Setup (For Users and AI Agents)

Fork this Repository (Recommended for Users):

If you intend to use this tool to manage your articles, first fork the devto-article-cli repository to your own GitHub account. This creates your personal copy where your articles will be stored.

Clone Your Forked Repository:

git clone https://github.com/YOUR_USERNAME/devto-article-cli.git
cd devto-article-cli
# Replace YOUR_USERNAME with your GitHub username.

Install Dependencies:

Navigate to the cloned/created directory and install the necessary Node.js packages:
```
npm install
```
Build TypeScript:

This process will generate dist directory:
```
npm run build
```
Set Dev.to API Key:

Obtain your API key from your Dev.to Settings > Extensions page.

Set it as an OS environment variable named DEV_TO_API_KEY.

-   **Windows (Command Prompt/PowerShell)**:

    ```
    # Command Prompt
    setx DEV_TO_API_KEY "your_api_key"
    # PowerShell
    [System.Environment]::SetEnvironmentVariable('DEV_TO_API_KEY', 'your_api_key', 'User')
    ```

    Restart your terminal after setting.

-   macOS (if using zsh):

    Add to ~/.zshrc:

    ```
    echo 'export DEV_TO_API_KEY="your_api_key"' >> ~/.zshrc && source ~/.zshrc
    ```

-   Linux (if using bash):

    Add to ~/.bashrc:

    ```
    echo 'export DEV_TO_API_KEY="your_api_key"' >> ~/.bashrc && source ~/.bashrc
    ```

If this environment variable is not set when the script runs, a message prompting you to set it will be displayed.

Initial Git Configuration (Important!):

Ensure your Git remote origin points to your forked repository on GitHub. If you cloned your fork, this should be set correctly. You may need to configure your Git user name and email if you haven't already:
```
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
```
Ready to Go!:

You are now set up. Use the commands below to manage your articles. Changes will be pushed to your forked repository.

Usage (For Users and AI Agents)

This tool provides three core commands. AI agents should be instructed to use these commands as described.

Creating a New Article (`article:new`)

To create a new article boilerplate:

npm run article:new

AI Agent Interaction:

Execute the command npm run article:new.
The script will prompt: "Enter the title of the article:". Provide the desired article title.
The script will then prompt: "Enter the slug for the filename (e.g., my-awesome-post):". Provide a URL-friendly slug.
A new Markdown file (e.g., articles/YYYY-MM-DD-HH-mm-ss-slug.md) will be created. Its front-matter will include the title and published: false.
The AI agent should then populate this file with the article content. For images, save them within this repository (e.g., in articles/images/) and use relative paths in the Markdown (e.g., ![My Alt Text](https://raw.githubusercontent.com/ken-okabe/devto-article-cli-private/main/articles/images/cool-pic.png)).

Publishing/Updating Articles (`article:publish`)

To publish new articles or update existing ones (from the articles/ directory) to Dev.to and sync with GitHub:

npm run article:publish

AI Agent Interaction:

Ensure the article content within the .md files in the articles/ directory is complete and ready for publishing. Ensure any images used are committed to the repository and referenced using relative paths in the Markdown. Adjust the published field in the front-matter to true if the article should go live.
Execute the command npm run article:publish.
The script will automatically:

-   Scan all `.md` files in the `articles/` directory.

-   **Convert local relative image paths to absolute GitHub Raw URLs** temporarily for sending to Dev.to.

-   For new articles (no `dev_to_article_id`): Post to Dev.to and add the new ID to the local file's front-matter.

-   For existing articles (`dev_to_article_id` present): Update the article on Dev.to.

-   `git add` all processed and modified local files (including images if they were added/changed and the article file).

-   `git commit` these changes with a summary message.

-   `git push` the commit to the remote GitHub repository.

No manual Git commands are needed from the AI agent for this step. Console logs will indicate success or failure.

When posting with images from a repository, the forked repository must be public because Dev.to cannot access images in private GitHub repositories.

For text-only posts, the forked repository can be private as no such web links are generated. Alternatively, if images are hosted separately where Dev.to can access them, the forked repository can also remain private.

Checking Consistency (`article:check`)

To check for discrepancies between local articles and those on Dev.to:

npm run article:check

AI Agent Interaction:

Execute the command npm run article:check.
The script will report:

-   Local articles with IDs: Verifies their existence and title on Dev.to.

-   Local articles without IDs: Lists them as unpublished.

-   Dev.to articles: Checks if corresponding local files (by ID) exist.

The AI agent can parse the console output to understand the consistency status and inform the user or take further actions if discrepancies are critical. This command is read-only.

Front-matter (For AI Agents)

At the beginning of your article Markdown files, include YAML front-matter like the following:

---
title: "My Awesome Article Title"
published: false # true to publish, false to send as draft to Dev.to. Default is false.
tags: ["javascript", "tutorial", "webdev"], Array of tags
series: "Intermediate JavaScript Series" # Optional
# Use absolute URLs for main_image and canonical_url if needed
main_image: "https://..." # Optional: URL to the main image
canonical_url: "https://..." # Optional: URL to the original source
description: "\"This article explains advanced JavaScript techniques.\" # Optional"
# dev_to_article_id: 12345 # Automatically added/updated on publish
---

## Article Body Starts Here
Write freely in Markdown...

Include images using relative paths to files within this repository:
![Alt text for my image](https://raw.githubusercontent.com/ken-okabe/devto-article-cli-private/main/articles/images/my-local-image.jpg)

Troubleshooting (For AI Agents)

API Key Error: Ensure the DEV_TO_API_KEY environment variable is correctly set.
Git Error: Ensure your Git authentication (SSH keys or HTTPS credentials) is correctly set up for pushing to your remote repository. Ensure you have committed initial files if it's a new repository and that the remote origin is correctly configured.
Image Not Found on Dev.to: Ensure the image file exists in your repository at the path referenced in the Markdown, and that you have pushed the commit containing the image before running publish. The automatic URL conversion relies on the image being accessible via its GitHub Raw URL.
If other error messages appear, check their content.

my first article via devto-article-cli

Ken Okabe — Wed, 07 May 2025 21:40:05 +0000

test

edit

edit2

edit3

The Future of AI-Driven API Integration and the Rise of MCP v2

Ken Okabe — Wed, 07 May 2025 09:53:05 +0000

The Future of AI-Driven API Integration and the Rise of MCP

Introduction

The integration of AI with various APIs is rapidly transforming the landscape of automation, content creation, and digital workflows. As AI systems become more capable of understanding and utilizing public APIs, the potential for seamless, intelligent automation grows exponentially.

AI and API Collaboration

AI assistants can now read, interpret, and interact with API documentation, enabling them to design and implement workflows that automate complex tasks. For example, as demonstrated in this repository, an AI can:

Read API documentation (such as Forem/Dev.to)
Generate scripts to automate publishing, editing, and managing content
Adapt workflows to new requirements with minimal human intervention

This capability allows for:

Rapid prototyping and deployment of automation
Reduced manual effort and human error
Greater flexibility and scalability in digital operations

The Rise of Model Context Protocol (MCP)

Model Context Protocol (MCP) is an emerging standard that aims to unify how AI models interact with tools, APIs, and external systems. MCP provides a structured way for AI to:

Discover available APIs and tools
Understand their capabilities and constraints
Safely and reliably invoke actions or retrieve data

With MCP, the boundaries between AI, APIs, and traditional software blur, enabling:

More robust and secure automation
Easier integration across platforms and services
A foundation for future AI-native applications

Looking Forward

As AI and protocols like MCP mature, we can expect:

Even more autonomous, context-aware workflows
AI-driven orchestration of multi-step, cross-platform processes
New opportunities for developers and organizations to leverage AI as a first-class automation agent

Conclusion

The synergy between AI and APIs, accelerated by standards like MCP, is set to redefine how we build, automate, and scale digital solutions. Staying informed and experimenting with these technologies will be key to unlocking their full potential.

Automating Dev.to Article Publishing with GitHub Actions and Node.js: A Workflow Overview

Ken Okabe — Wed, 07 May 2025 09:26:37 +0000

Automating Dev.to Article Publishing with GitHub Actions and Node.js: A Workflow Overview

This document outlines a workflow for automating the publishing of Markdown articles to Dev.to using Node.js scripts and GitHub Actions. The actual implementation (such as scripts and configuration files) can be generated by AI or created by a developer, making this guide suitable for both human and AI readers.

Forem and the Dev.to API as the Foundation

This workflow is designed based on the fact that Dev.to is built on the Forem platform. Forem provides a public API (see: https://developers.forem.com/api/v1) that enables programmatic interaction with Dev.to, including publishing articles, retrieving user data, and more.

For this workflow, the AI assistant (not the user) has read and understood the Forem API documentation. The automation process leverages the API's article publishing endpoints, allowing scripts to post Markdown content directly to Dev.to. This ensures the workflow is robust, up-to-date, and aligned with Dev.to's official capabilities.

By utilizing the Forem API, this workflow can be adapted or extended to other Forem-based communities in the future, not just Dev.to.

1. Overview

The goal is to enable automatic publishing of Markdown articles to Dev.to whenever new content is pushed to a GitHub repository. This is achieved by combining:

A Node.js script (generated by AI or written by a developer) that reads Markdown files and posts them to the Dev.to API.
A GitHub Actions workflow that triggers the script on repository updates.

2. Workflow Steps

Prepare Your Repository Structure
- Organize your articles in a dedicated directory (e.g., articles/).
- Place your automation script (e.g., publish-to-devto.js) at the project root.
- Set up a GitHub Actions workflow file in .github/workflows/.
Generate the Node.js Script
- The AI assistant, in agreement with the user, determined that robust article management (including update/overwrite support) is essential for practical operation.
- The AI implemented a solution where:
  - Each article file is associated with a unique Dev.to article ID, managed in a metadata file.
  - On new article creation, the script saves the returned Dev.to ID for future updates.
  - On subsequent edits, the script uses the stored ID to update the corresponding Dev.to article instead of creating duplicates.
- Use an AI tool or write a script that:
  - Reads Markdown files with front matter (title, tags, etc.).
  - Formats the content for the Dev.to API.
  - Sends HTTP requests to publish articles using the Dev.to API key.
  - Manages article IDs for update/overwrite support.
Configure the GitHub Actions Workflow
- Create a workflow YAML file that:
  - Runs on push events (e.g., when articles are added or updated).
  - Installs necessary dependencies (as specified by the script).
  - Executes the Node.js script.
  - Uses repository secrets to securely provide the Dev.to API key.
Store Secrets Securely
- Add your Dev.to API key as a GitHub Actions secret (e.g., DEVTO_API_KEY).
Publish Workflow
- When a new article is pushed, the workflow runs automatically.
- The script posts the article to Dev.to without manual intervention.

Important Notes for Dev.to API Usage

Tag Limit: The Dev.to API allows a maximum of 4 tags per article. If you specify more than 4 tags in your Markdown front matter, the API will return an error and the article will not be published. Always ensure your tags array contains 4 or fewer items.
Error Handling: If the workflow fails, check the number of tags and other required fields in your article front matter first.

3. Notes for AI or Human Implementers

The actual code for the Node.js script and workflow file can be generated by an AI assistant or written manually.
Ensure that dependencies (such as HTTP and Markdown parsing libraries) are included as needed.
Follow best practices for API authentication and error handling.
This workflow is adaptable: you can extend it to support other platforms or additional automation steps.

4. Example Use Case

A user writes a Markdown article and pushes it to the repository.
The GitHub Actions workflow is triggered.
The AI-generated script publishes the article to Dev.to using the API.

This document serves as a conceptual guide. For concrete implementation, use an AI tool or refer to sample scripts and workflow files tailored to your needs.

VanFS Released

Ken Okabe — Sat, 04 May 2024 20:32:51 +0000

https://github.com/ken-okabe/vanfs

Does the functionality of Grouping operator () in JavaScript differ from Haskell or other programming languages?

Ken Okabe — Thu, 30 Sep 2021 20:27:34 +0000

Grouping operator ( ) in JavaScript

The grouping operator ( ) controls the precedence of evaluation in expressions.

does Not differ from Haskell or other programming languages. (there is a minor exception as a byproduct of their main purpose in Lisp/Clojure)

In other words, grouping operator ( ) in every language shares the common functionality to compose Dependency graph

In mathematics, computer science and digital electronics, a dependency graph is a directed graph representing dependencies of several objects towards each other. It is possible to derive an evaluation order or the absence of an evaluation order that respects the given dependencies from the dependency graph.

and the functionality of Grouping operator ( ) itself is not affected by a evaluation strategy

Perhaps we can share the code below:

f() * (g() + h())

to discuss the topic here, but not limited to the example.

Haskell

In the code in Haskell where the evaluation strategy is Lazy / Call-by-need

https://en.wikipedia.org/wiki/Lazy_evaluation

In this code, according to the call-by-need, the evaluation order of f g h is

h(1) -> f(1) -> g(1)

In this code, according to the call-by-need, the evaluation order of f g h is

f(1) -> g(1) -> h(1)

JavaScript

//function definition  
const f = a => a + 1;  
const g = a => a + 2; 
const h = a => a + 3; 

//calling functions 
console.log( 
(f(1) * g(1)) + h(1) 
); //10 
console.log( 
f(1) * (g(1) + h(1))   
); //14

In this code, according to the eager-evaluation the evaluation order of f g h is

f(1) -> g(1) -> h(1)

in both cases.

Either way, the regardless the evaluation strategies, since the dependency graph composed with Groping operator() and + * stays identical, the final evaluated value is also identical.

TC39/proposal-pipeline-operator Hack-style |> hijacks Grouping operator ( )

Ken Okabe — Sat, 25 Sep 2021 23:28:23 +0000

TC39 proposal Hack Pipeline Operator |> is incompatible with Grouping operator ().

Short version

Grouping operator `( )`

The grouping operator ( ) controls the precedence of evaluation in expressions.

The grouping operator consists of a pair of parentheses around an expression or sub-expression to override the normal operator precedence so that expressions with lower precedence can be evaluated before an expression with higher priority.

Test Code 1:

const f = a => a * 2;
const g = a => a + 1;

1 |> f(^) |> g(^);
1 |> (f(^) |> g(^));

Now we made (f(^) |> g(^)) to be evaluated before other expressions with higher priority.

I've investigated with Babel, and the transpiled result is identical, which means:
(f(^) |> g(^)) is NOT evaluated before other expressions with the rule of Grouping operator ( ).

Does the current proposal Hack |> hijack the Grouping operator ?

Test Code 2:

Now I have a log function.

const right = a => b => b;
const log = a => right(console.log(a))(a);

This behaves like identity function: a => a which does not affect to the original code but console.log(a) in the process.

Now, we want to know the evaluated value of (f(%) |> g(%))

1 |> (log(f(%) |> g(%)));

This should be totally fine because (f(%) |> g(%)) must have some value of the evaluation according to:

The grouping operator consists of a pair of parentheses around an expression or sub-expression to override the normal operator precedence so that expressions with lower precedence can be evaluated before an expression with higher priority.

The vanilla JS code is:

var _ref, _ref2, _ref3, _ref4;
const id = a => a;
const right = a => b => b;
const log = a => right(console.log(a))(a);
const f = a => a * 2;
const g = a => a + 1;
_ref2 = 1, (_ref = f(_ref2), g(_ref));
_ref4 = 1, log((_ref3 = f(_ref4), g(_ref3)));

and the result is:
3

Therefore,

1 |> (f(%) |> g(%));

where (f(%) |> g(%)) == 3

1 |> (f(%) |> g(%))
==
1 |> 3

???

and the evaluation value of whole 1 |> (f(%) |> g(%)) is 3
therefore,
1 |> 3 == 3

I have no idea for this hack-pipe-operator, and simply think this has broken the laws of Mathematics, and more importantly, it seems the current proposal Hack |> hijacks the Grouping operator

The Babel implementation

https://github.com/tc39/proposal-pipeline-operator/issues/227#issuecomment-926136875

The Babel implementation has been done by @js-choi (one of the champions of the Hack pipes proposal).

The "reasonable stardard" is the spec proposal: either you learn how to read it (I'd be happy to help, if you are confused about any spec part), or you trust what who can read it says.

Issue

In fact, I made an issue for this.

Does the current proposal override the Grouping operator ( ) with Hack |> ? #229
https://github.com/tc39/proposal-pipeline-operator/issues/229

https://github.com/tc39/proposal-pipeline-operator/issues/229#issuecomment-926308352

As had been explained already, parentheses don't work the way you seen to think they do. The result you're getting from Babel is entirely correct and expected, with exactly the same precedence and execution order that you'd get from parenthesizing a sequence of additions.

As this question has been answered, I'm closing this thread.

Issue closed with the tag of invalid, well, I don't think so.

@js-choi has explained to me for sure:

https://github.com/tc39/proposal-pipeline-operator/issues/227#issuecomment-926317660

@js-choi explanation

Hm. Well…I don’t think anyone is admitting or covering anything up. But I’ll give it a shot; hopefully this will help a little. ^_^

Parentheses change grouping. But they never have changed evaluation order, which is always left to right, even outside of parentheses. This is how JavaScript (and many other programming languages) have always been:

function f () {
  console.log('F');
  return 3;
}

function g (x) {
  console.log('G');
  return x + 4;
}

function h (x) {
  console.log('H');
  return x * 7;
}

// This will print F then G then H, and it will result in 3 * 12, i.e., 36.
`f() * (g(1) + h(1))`

Note how the f() evaluates first even before (g(1) + h(1)), despite (g(1) + h(1)) being in parentheses. That’s why F still prints first before G and H.

Parenthesized expressions are not always evaluated first; expressions outside of the parentheses to the left are evaluated beforehand. This has how JavaScript (and many other languages like C and Lisp) have always been.

Parentheses change grouping. But they have never changed evaluation order, which is always left to right, even outside of parentheses. This is how JavaScript (and many other programming languages) have always been:

// f, g, and h have the same definitions above.

// This will print F then G then H, and it will result in 3 * 12, i.e., 36.
f() * (g(1) + h(1))

// This will also print F then G then H, and it will result in 7 * 7, i.e., 49.
f() |> (g(^) |> h(^))

Note how the f() evaluates first even before (g(1) + h(1)), despite (g(1) + h(1)) being in parentheses. That’s why F still prints first before G and H.

This is the same reason why f() |> (g(^) |> h(^)) causes f() to be evaluated before (g(^) |> h(^)).

Just like how f() * (g(1) + h(1)) causes f() to be evaluated before (g(1) + h(1)).

It’s just the old left-to-right evaluation rules. There aren’t any special grouping rules here. Parentheses change the grouping, but they never have changed execution order from anything other than left to right.

Hopefully that clears it up a little! I can understand why it might be a little confusing, but it’s just the old rules. Nothing is happening here except for the old JavaScript evaluation/parentheses rules. ^_^

(Actually, perhaps I should also edit MDN’s documentation to make this clearer. Maybe this old parenthesized-expressions-are-not-always-evaluated-first rule is tripping up many people learning JavaScript.)

My explanation

#227 (comment) @jridgewell

Notice the order "two", "three", "four" isn't affected by the parenthesis. Let's try (two() * three()) + four(). Surprise, it's still "two", "three", "four"! But now the final log is 10. That's because the operands are evaluated left to right, and this doesn't change. What changed was the evaluation of the operators.

#227 (comment) @js-choi

Note how the f() evaluates first even before (g(1) + h(1)), despite (g(1) + h(1)) being in parentheses. That’s why F still prints first before G and H.

I observe, again, two of you share the same concept, and there are confusion of concepts . So I will explain to you. Hope it helps, really.

Confusion of concepts

The problem you illustrated is not for inconsistency or limitation of the functionality of the Grouping operator ( ) but evaluation strategy of JS that is eager-evaluation, in this evaluation strategy, f(x) is evaluated as soon as it is found from left to right, yes, you are only correct here.

The only "safe" place is right side of lambda expressions: such as a => f(a). In this case, even it's found by compiler f(a) is safe! will not be evaluated. (the same goes to function statement). Therefore the technique is used to emulate lazy-evaluation. Another exception is true || f(x) but false || f(x) will be evaluated once found. Try it.

Then point is, what you told us is nothing to do with the evaluation order of binary operator or Grouping operator ( ).

The eager evaluation strategy strictly follows the Algebraic rule. Well, if you can find anomaly, show me :) It follows the rule of operators including Grouping operator () with no exceptions. The eager evaluation of f(x) never harms Algebraic expression in JS. If both of you have explained as if eager evaluation of f(x) is the limit of the math in JS. That is the harmful explanation for us.

Sure in your code, we will have F G H or two three four order and so what? Does it break the rule of the math or algebraic structure? Nah..

Parentheses change grouping. But they never have changed evaluation order, which is always left to right, even outside of parentheses. This is how JavaScript (and many other programming languages) have always been:

So, this is a false statement.

The tricky word is: evaluation "order".

Note how the f() evaluates first even before (g(1) + h(1))

So another tricky term should be : "before" or "after"

In mathematics, when we use the term "order" "before" "after", does it mean time series? No way.

Does it mean the order of the line of terminal console?

This logs:

"two"

"three"

"four"

Doesn't matter in terms of math structure.

What does matter is dependency network structure.

Binary operation is merely a syntax-sugar of binary function, and when you chain them, you fundamentally compose the functions.

For instance, when you enjoy + binary operation, you guys repeatedly told me "left to right", but fundamentally you do

This is Fold

https://en.wikipedia.org/wiki/Fold_(higher-order_function)

There are both left and right side fold, and usually we use foldLeft and if it's monoid the result is the same of both side.

As you seen, this is a Graph. Dependency graph

In mathematics, computer science and digital electronics, a dependency graph is a directed graph representing dependencies of several objects towards each other. It is possible to derive an evaluation order or the absence of an evaluation order that respects the given dependencies from the dependency graph.

Remember "evaluation order" derived from the dependency graph or structure is completely different concept of "time order" of executions.

Hack pipe

Hack pipe, on the other hand, unlike eager evaluation strategy, this does break the math structure, and again this one overrides Grouping Operator ( ). I meant in dependency base. This problem is elaborated in my previous post #227 (comment)

I don't think it's on purpose, but the confusion of concept of Evaluation strategy and Algebraic structure is harmfully explained to justify the false design of Hack pipe that overrides the operator with the highest precedence in JS.

I will maintain my claim:

Does the current proposal override the Grouping operator ( ) with Hack |> ? #229

Deletion of my explanation

@js-choi

It’s just the old left-to-right evaluation rules. There aren’t any special grouping rules here. Parentheses change the grouping, but they never have changed execution order from anything other than left to right.

So this is a false statement.

So why there's no link to my explanation? Deleted by them.

https://github.com/tc39/proposal-pipeline-operator/issues/227#issuecomment-926737650

I have just deleted several comments from @stken2050 (and a few responses to them from others) that were explicitly continuing the confused argument about parentheses that I said just a few hours ago to not continue. I'm closing and locking this thread, and pursuing separate moderation actions, as I said I would if this behavior continued.

Ok.

that were explicitly continuing the confused argument about parentheses that I said just a few hours ago to not continue.

So individuals who are confused are not me but the members to promote this Hack proposal, and they believe they have a power to tell which argument is to be allowed to continue or not. In other words, this is an abuse of power or Censorship to justify their own proposal for their own interest to achieve the standardization of this false Hacked product.

Sure, I claimed to TC39, and I've got a mail from an individual on behalf of TC39 Chairs & CoC Committee:
https://gist.github.com/stken2050/5eff7d2a792cd2b9e773b09c64fd26da

Therefore, I understand TC39 has justified their abuse of power of censorship, and Banned me for 2 weeks.

EDIT (2021/9/28):
Now they added a false statement to the MDN page of Grouping operator ( ), for the purpose of justifying their own proposal that is based on the confusion of the concept: "evaluation order" derived from the dependency graph or structure is completely different concept of "time order" of executions.

Please confirm here:
Description confusing concepts clarified #9389

The point of view here has been shared in stack overflow question , and a third person confirmed the fact as the answer:

Grouping parentheses mean the same thing in Haskell as they do in high school mathematics. They group a sub-expression into a single term. This is also what they mean in Javascript and most other programming language,

A language needs other rules beyond just the grouping of sub-expressions to pin down evaluation order (if it wants to specify the order), whether it's strict or lazy. So since you need other rules to determine it anyway, it is best (in my opinion) to think of evaluation order as a totally separate concept than grouping. Mixing them up seems like a shortcut when you're learning high school mathematics, but it's just a handicap in more general settings.

Therefore, for the explanation of Grouping operator (parentheses) itself, the priority of the article should be to focus the functionality given as the meaning of "high school mathematics".

The wording of old version "operands" of "preserved" actively misleads readers to confuse the "high school mathematics" principle of the Grouping operator and the evaluation strategy of JavaScript runtime.

If anyone think such an example is required and to be included in this page, they need to explain thoroughly for readers to avoid the confusion of concepts between the mathematical aspect and evaluation strategy that the latter is essentially off-topic here.

Reference material

Does the functionality of Grouping operator () in JavaScript differ from Haskell or other programming languages?

https://stackoverflow.com/a/69386130/11316608

Long version

What is grouping-operator?

Grouping operator `( )`

The grouping operator ( ) controls the precedence of evaluation in expressions.

The grouping operator consists of a pair of parentheses around an expression or sub-expression to override the normal operator precedence so that expressions with lower precedence can be evaluated before an expression with higher priority.

Grouping operator ( ) itself has the highest precedence in JavaScript.

Operator precedence

What is pipeline-operator?

In a general sense, pipeline-operator |> is a binary operator for function application that is equivalent to f(x)

f(x) == x |> f

Benefit of binary operator

Introducing a new binary-operator in JavaScript is nothing new.

In ES2016, exponentiation operator ** has been introduced.
Math.pow(2, 3) == 2 ** 3
Math.pow(Math.pow(2, 3), 5) == 2 ** 3 ** 5

As you can see, a binary operator significantly improve the readability of a code, especially for the nesting structure of f() notation,

Essentially, pipeline-operator is the same league of the exponentiation operator, and the benefit is also common.

g(f(x) == x |> f |> g

Expectation of the community

In fact, pipeline-operator in JS has been expected from the community.

#StateOfJS 2020: What do you feel is currently missing from JavaScript?

Static Typing
Pattern Matching
Pipe Operator
functions
Immutable Data Structure

It's reasonable to observe that the majority of the JS community has longed for more strictness of the language.

Especially for Static Typing:

Why Static Typing is so popular?

There is no native static type system in JavaScript, so currently, many use TypeScript instead.
So why do we like Type so much?

The general answer would be that we can avoid BUGs, in other words Type makes a code robust.

Why Type makes a code robust?

Because Type is mathematics.
I will explain briefly about Type since I think the understanding helps readers follow this discussion.

Types as Sets

Type == Sets

Type theory versus set theory

Alternately, we could change our terminology so that what we have been calling “types” are instead called “sets”.

Thus, words like “type” and “set” and “class” are really quite fungible. This sort of level-switch is especially important when we want to study the mathematics of type theory,

Types as Sets · An Introduction to Elm

In pursuit of this goal, I have found it helpful to understand the relationship between types and sets. It sounds like a stretch, but it really helps develop your mindset!

What is Sets?

Definition of Function

https://en.wikipedia.org/wiki/Function_(mathematics)#Definition

Intuitively, a function is a process that associates each element of a set X, to a single element of a set Y.

https://ncatlab.org/nlab/show/function

In a strict sense of the term, a function is a homomorphism f:S→Tf : S \to T of sets. We may also speak of a map or mapping, but those terms are used in other ways in other contexts.

So, in the definition of function, we need to define the sets of x and y
where y = f(x), or x |> y

A binary operator is a syntax-sugar of binary functions

Binary operation

As you can see in the picture,
x * y == f(x, y)

or should I edit this picture to

A binary operator is a syntax-sugar of binary functions.
We also need to type (== sets) x and y or f correctly as the request from the mathematical definition of function, and according to the overwhelming popularity of Static Typing in the survey, that is what people want. They needs more strictness of JavaScript for their robust codes.

For x |> f === f(x), essentially it's clearly typed:

x : JavaScript Objects
f : Function

Then, since this is f(x), the type(==sets) of x should be defined along with the definition of f.

This is what people want.

Hack-style reached Stage-2

Recently, I have noticed JS pipeline-operator has reached TC-39 Stage-2, so I have examined:
tc39/proposal-pipeline-operator

Pipe Operator (`|>`) for JavaScript

Why the Hack pipe operator

There were two competing proposals for the pipe operator: Hack pipes and F# pipes. (Before that, there was a third proposal for a “smart mix” of the first two proposals, but it has been withdrawn, since its syntax is strictly a superset of one of the proposals’.)

The two pipe proposals just differ slightly on what the “magic” is, when we spell our code when using |>.

This proposal: Hack pipes

In the Hack language’s pipe syntax, the righthand side of the pipe is an expression containing a special placeholder, which is evaluated with the placeholder bound to the result of evaluating the lefthand side's expression. That is, we write value |> one(^) |> two(^) |> three(^) to pipe value through the three functions.

Pro: The righthand side can be any expression, and the placeholder can go anywhere any normal variable identifier could go, so we can pipe to any code we want without any special rules:

value |> foo(^) for unary function calls,
value |> foo(1, ^) for n-ary function calls,
value |> ^.foo() for method calls,
value |> ^ + 1 for arithmetic,
value |> [^, 0] for array literals,
value |> {foo: ^} for object literals,
value |> `${^}` for template literals,
value |> new Foo(^) for constructing objects,
value |> await ^ for awaiting promises,
value |> (yield ^) for yielding generator values,
value |> import(^) for calling function-like keywords,
etc.

What??
I had a hope for value |> f is still valid, but syntax-error.

The type of right hand side of |> is no longer function but something unknown.

Reactions

I investigated the issue of this proposal.

#200: Added value of hack-style proposal against temporary variables https://github.com/tc39/proposal-pipeline-operator/issues/200
#202: Separate (complementary) F# pipeline proposal? https://github.com/tc39/proposal-pipeline-operator/issues/202
#205: Hack is dead. Long live F#. https://github.com/tc39/proposal-pipeline-operator/issues/205
#206: Should enabling point-free programming/APIs be a goal of the Pipeline Operator? https://github.com/tc39/proposal-pipeline-operator/issues/206

In fact, #205: Hack is dead. Long live F#. has 199 comments and now closed by moderator.
https://github.com/tc39/proposal-pipeline-operator/issues/205#issuecomment-918717394

This is a huge thread and reading there, I've watched the issue was closed in real-time.

Here are few comments I've found around threads:

#205 (comment) @jderochervlk

The future of functional programming is Hack pipe

Nope. It isn't. If this is truly what became added to the language I would continue to use Ramda's pipe, which is a shame because I would really love to remove some overhead of installing a package in order to do something so simple.

#205 (comment) @samhh

I'm thinking ahead. JavaScript won't cease to exist once Hack reaches stage 4.

#215 (comment) @arendjr

I would rather have the language remain without any pipe operator than to have to deal with Hack in the future.

I too would like to thank @js-choi and the other contributors for all their effort, but I believe the current direction to be misguided to the detriment of not just the FP community, but the JS community at large.

#225 (comment) @voronoipotato

The argument against hack pipes is that we believe they are a hazard (sometimes for different reasons, but the conclusion is the same). Most of us in this thread and I suspect in the wild, would rather have no pipes, than hack pipes.

#225 (comment) @SRachamim

PFA proposal is a universal solution to those who worries about the arrow function noise on all three cases: map, then and pipe. If PFA is not ready, and we don't want minimal/F# without PFA, then let's wait, instead of introducing an irreversible Hack pipes.

#225 (comment) @SRachamim

And as I said, if PFA is stuck, then it's not a good reason to introduce Hack. We should either wait, or avoid pipe at all (or introduce minimal/f# style anyway).

#225 (comment) @Lokua

Also, as a writer whose job is to communicate meaning, hack style removes my ability to provide descriptive names, which is basically the universal first step of writing readable code. I'm honestly shocked at this proposal. Imagine if you started at a new company and they enforced that all unary functions you write regardless of context had to name their single argument x (or god forbid, ^ ). That's how I feel and I'm not exaggerating - this proposal scares me because it's going to lead to code that is uglier, harder to read, and harder to refactor/abstract later on!

Edit: I too would rather see no pipe than this and am admittedly biased as I've always thought a pipe operator (or pretty much any more new syntax) is a bad idea. But if we are going to have it, I'd rather see it implemented in a way that improves readability, not (IMHO) hinders it.

I've found they claim it's far better not to have any pipe than to have hack-style because they evaluated the one harmful to JavaScript.

This is a comment by RxJS auhthor
https://github.com/tc39/proposal-pipeline-operator/issues/228#issuecomment-925465598

I've been told several influential members want to discourage point-free programming. Therefore, anything that might help functional programming libraries is unlikely to pass the TC39. It is what it is. It's the hack proposal or nothing. IMO, the hack proposal isn't useful enough to justify the additional syntax. But I'm not on the committee

Please don't @ me into these threads. I've said my piece. Pretty thoroughly. I wasn't really heard. And I lost a friend over it. I simply just don't care what happens with this anymore. If it passes, great. Unfortunately, I don't really have any use for the proposed pipeline operator. But I'm hopeful for other features someday that I will have a use for.

History of the proposal

I think it's fair to share the history posted by a project member @js-choi

Brief history of the JavaScript pipe operator

My study on Hack

In fact, I had to study the Hack-style-pipeline-operator.
I had no idea what this is.
For the minimal/F# proposal, it's merely x |> f === f(x) , so simple, no requirement to study.

I had joined issues, and also I've opened a couple of issues by myself, and actually lots of text here is copy&paste of my own comment there.

Pipeline-operator in a mathematical sense

Before I discuss Hack pipe, I share my knowledge on the pipeline-operator in a mathematical sense that is
x |> f === f(x)

Associative property and Monoid

Addition

https://en.wikipedia.org/wiki/Addition#General_theory

General theory

The general theory of abstract algebra allows an "addition" operation to be any associative and commutative operation on a set. Basic algebraic structures with such an addition operation include commutative monoids and abelian groups.

Here the important property is associative

(1 + 2) + 3 = 
1 + 2 + 3 = 
1 + (2 + 3)

JS String is also has associative property, and they are called Monoid in algebra.

In abstract algebra, a branch of mathematics, a monoid is a set equipped with an associative binary operation and an identity element.

Associativity

For all a, b and c in S, the equation (a • b) • c = a • (b • c) holds.

In computer science and computer programming, the set of strings built from a given set of characters is a free monoid.

What does this mean?

"Hello" + " " + "operator" ==
"Hello " + "operator" ==
"Hello" + " operator" ==
"Hello operator"

Strings and + the binary operator in JS is a Monoid, and as you know this String operator is very easy to use and robust.

Monoid or associative property has rock solid structure because it's hardly broken.

Imagine LEGO block, that is also Monoid, the order to construct block does not effect the result:

(A + B) + C = 
A + B + C = 
A + (B + C)

Any order to construction of the combination of LEGO bock reaches the identical result. So in software development if the entity has Monoid property, we can treat it as if LEGO block. That's the virtue of Monoid. Just its like LEGO, wonderful stuff.

Without the associative property, we will experience Combinatorial explosion.

In mathematics, a combinatorial explosion is the rapid growth of the complexity of a problem due to how the combinatorics of the problem is affected by the input, constraints, and bounds of the problem.

The history of software development is the war against complexity.

In fact, Associativity is one of the most important concept in programming and Associativity is the key to avoid the software complexity that is the fundamental reason of BUGs . In other words, as long as we are very carful to keep things with associative property, we safely can avoid complexity and obtain a bug-free code.

So Associativity is important, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Exponentiation

They care a lot.

Function composition as a Monoid

https://en.wikipedia.org/wiki/Monoid

For example, the functions from a set into itself form a monoid with respect to function composition.

I will explain this.

One of "the functions from a set into itself" is addition.

// function from a set into itself
const f = a => a + 1; // f: number -> number 
const g = a => a + 2; // g; number -> number

please note I use the composition operator for g(f(x)) not g.f but f.g

a |> f |> g   ===
a |> (f . g)

This is the simple structure of
Function application (pipeline-operator)
Function composition (composition-operator).

They are the both side of the same coin.

(f.g).h === f.g.h === f.(g.h)

Therefore, function composition is Monoid.

a |> f |> g |> h ===
a |> f |> (g . h) ===
a |> f . (g . h) ===
a |> (f . g) |> h ===
a |> (f . g) . h ===
a |> (f . g . h)

where f.g is the composition of f and g

(in traditional math style is g.f regarding g(f) but I don't use this style )

This is the whole picture you should know, and as you can see:

function application |> is not associative and not Monoid.

a |> f |> g   !=
a |> (f |> g)

The (f |> g) does not make sense and the Type==Sets is violated in terms of x |> f.

However, this is what the Hack style is doing.

const f = a => a * 2;
const g = a => a + 1;

1 |> f(^) |> g(^);    //3
1 |> (f(^) |> g(^));  //3

and (f(^) |> g(^)) is also evaluated as 3,
with the higher priority of general rule of Mathematics or grouping-operator ()

as a result

1 |> 3 == 3

This does not make sense at all, and the fundamental reason is they simply violates the rule of mathematics.

Monad

Pipeline-operator |> and function application does not have associative property in Monoid layer, but the form

a |> f |> g   ===
a |> (f . g)

is also called Associativity in Monad layer.

https://wiki.haskell.org/Monad_laws

Monad laws

For your convenience, I would rewrite to

Associativity: (m |> g ) |> h === m |> (x => g(x) |> h)
or
Associativity: (m |> g ) |> h === m |> (x => x |> g |> h)
as (x => x |> g |> h) is the function composition of g and h
Associativity: (m |> g ) |> h === m |> (g . h)

For left-right identity,

with identify function: id= x => x
For every Function: f: A ->B
If this forms, the algebraic structure is called Monad.
Note: this corresponds to Monoid has associativity and identify.

Function Application |> Monad
Function Composition . Monoid also Monad (obvious, but prove by yourself)

So mathematically, |> is Monad, not Monoid.

FYI,
Array.prototype.flatMap() introduced in ES2019
https://github.com/tc39/proposal-flatMap

https://github.com/tc39/proposal-flatMap/issues/10

This proposal essentially gives native Arrays the methods they need to work as Monads (without having to extend the prototype).

They add flatMap on purpose as Monad on top of the Map.

Pipeline-operator |> in the mathematical sense of function application is natively Monad that behaves pretty well with the rock-solid structure that majorities of programmers in JavaScript desired for, and now, Hack pipe destroys that. No respect to Mathematics.

Math structure of Hack pipe

F# pipe is simply mathematical function application, it behaves like Monad, so it's natural it does not behave Associative in Monoid.

Hack pipe, on the other hand, it behave like Associative and Monoid,

a |> f(^) |> g(^)   == 
a |> (f(^) |> g(^))

but this is not a monoid.
Something unknown to leads:
1 |> 3 == 3
This is something completely different from Function application in mathematical sense.

This one breaks the Algebraic structure that I've explained so far.
Function application is NOT Monoid and should not behave like Monoid.
Function composition is Monoid but with Hack pipe, there is no such a concept anymore because it has broken the mathematics.

With pipeline-operator in the algebraic sense,

a |> f |> g   ===
a |> (f . g)

This is Associative in Monad layer with Function composition that itself is Associative and Monoid/Monad in both layers.

Type of Hack pipe

I'll give it another shot.

As a type,

A |> F |> F |> F is replaced to
A * F * F * F
===
A * (F + F + F)
where
A * F is function application, and
F + F is function composition.

Hack on the other hand,
They claim the simplicity:
A * F * F * F
===
A * (F * F * F)
We no longer understand what the (F * F * F) is.
In fact, they say:
(F * F * F) itself is a syntax-error.
Sure it should be because it doesn't make sense, and
(F * F * F) is refused to be evaluated because they ignore the rule of grouping-operator.
In other words, they overrides a rule of the operator that has the highest precedence priority in JavaScript, that I would call hijack.
(F * F * F) is not a function composition like in F# or math pipe, nor anything understandable, so Type is ?
A * (?)
and (?) appears to be the evaluated value of the whole expression (such as 3):
? == A * (?)
therefore
A * (A * (A * (A * (A * (A * (A * (..?..)))))))
Some structure of infinite recursion.
That is the Type of the Hack pipe. Scary.

Hijacking grouping-operator `()`

As you can see,

Internally, technically, the Hack |> refuses to evaluate (f(%) |> g(%)) first ignoring the rule of

Grouping operator `( )`

The grouping operator consists of a pair of parentheses around an expression or sub-expression to override the normal operator precedence so that expressions with lower precedence can be evaluated before an expression with higher priority.

Grouping operator ( ) itself has the highest Operator precedence in JavaScript.

Then I hear the counter explanation to justify Hack pipe anomaly:
https://github.com/tc39/proposal-pipeline-operator/issues/227#issuecomment-926317660

It’s just the old left-to-right evaluation rules. There aren’t any special grouping rules here. Parentheses change the grouping, but they never have changed execution order from anything other than left to right.

"old left-to-right evaluation rules" that means eager evaluation strategy of JavaScript follows the rule in the sense of both Mathematics and grouping-operator ().

Eager evaluation does not conflict to evaluation order.

The evaluation order arises from Dependency graph

In mathematics, computer science and digital electronics, a dependency graph is a directed graph representing dependencies of several objects towards each other. It is possible to derive an evaluation order or the absence of an evaluation order that respects the given dependencies from the dependency graph.

and () defines the dependency graph and the structure of the code.

Remember dependency graph or structure is completely different concept of time order.

Here, in the terms of "evaluation order", "before", "after" we discuss Not time order of the evaluation/excision, but dependency structure of the code, which unfortunately it seems everyone in the Hack pipe proposal team share the confusion of the concept.
As we've seen, the Hack pipe refuses to follow the evaluation order of dependency structure and I would call this Hijacking grouping-operator ().

I did explain to them, but they did not hear, then deleted my explanation. That is why I made a post here.

Current TC39 proposal Hack Pipeline Operator |> has severe problems including the process of the staging, and the entire community of JavaScript will suffer.

I made Issues:
Issue with "Grouping operator ( )": (invalid statements added) #9306

Implicitly misleading into confusion of concepts: "Grouping operator ( )" #9317

Update Grouping operator ( ) #9325

Please confirm here:
Description confusing concepts clarified #9389

The point of view here has been shared in stack overflow question , and a third person confirmed the fact as the answer:

Grouping parentheses mean the same thing in Haskell as they do in high school mathematics. They group a sub-expression into a single term. This is also what they mean in Javascript and most other programming language,

A language needs other rules beyond just the grouping of sub-expressions to pin down evaluation order (if it wants to specify the order), whether it's strict or lazy. So since you need other rules to determine it anyway, it is best (in my opinion) to think of evaluation order as a totally separate concept than grouping. Mixing them up seems like a shortcut when you're learning high school mathematics, but it's just a handicap in more general settings.

Therefore, for the explanation of Grouping operator (parentheses) itself, the priority of the article should be to focus the functionality given as the meaning of "high school mathematics".

Also, my next article:

Does the functionality of Grouping operator () in JavaScript differ from Haskell or other programming languages?

DEV Community: Ken Okabe

All-in-One GitHub Repository-Driven Dev.to Article Management System

All-in-One GitHub Repository-Driven Dev.to Article Management System

Features

Prerequisites (For Users and AI Agents)

Setup (For Users and AI Agents)

Usage (For Users and AI Agents)

Creating a New Article (article:new)

Publishing/Updating Articles (article:publish)

Checking Consistency (article:check)

Front-matter (For AI Agents)

Troubleshooting (For AI Agents)

my first article via devto-article-cli

The Future of AI-Driven API Integration and the Rise of MCP v2

The Future of AI-Driven API Integration and the Rise of MCP

Introduction

AI and API Collaboration

The Rise of Model Context Protocol (MCP)

Looking Forward

Conclusion

Automating Dev.to Article Publishing with GitHub Actions and Node.js: A Workflow Overview

Automating Dev.to Article Publishing with GitHub Actions and Node.js: A Workflow Overview

Forem and the Dev.to API as the Foundation

1. Overview

2. Workflow Steps

Important Notes for Dev.to API Usage

3. Notes for AI or Human Implementers

4. Example Use Case

VanFS Released

Does the functionality of Grouping operator () in JavaScript differ from Haskell or other programming languages?

Haskell

JavaScript

TC39/proposal-pipeline-operator Hack-style |> hijacks Grouping operator ( )

Short version

Grouping operator ( )

Test Code 1:

Test Code 2:

The Babel implementation

Issue

@js-choi explanation

My explanation

Confusion of concepts

Hack pipe

Deletion of my explanation

Reference material

Long version

What is grouping-operator?

Grouping operator ( )

Operator precedence

What is pipeline-operator?

Benefit of binary operator

Expectation of the community

Why Static Typing is so popular?

Why Type makes a code robust?

Types as Sets

Type theory versus set theory

Types as Sets · An Introduction to Elm

What is Sets?

Definition of Function

A binary operator is a syntax-sugar of binary functions

Hack-style reached Stage-2

Pipe Operator (|>) for JavaScript

Why the Hack pipe operator

This proposal: Hack pipes

Reactions

History of the proposal

My study on Hack

Pipeline-operator in a mathematical sense

Associative property and Monoid

Function composition as a Monoid

Monad

Math structure of Hack pipe

Type of Hack pipe

Hijacking grouping-operator ()

Grouping operator ( )

Creating a New Article (`article:new`)

Publishing/Updating Articles (`article:publish`)

Checking Consistency (`article:check`)

Grouping operator `( )`

Grouping operator `( )`

Pipe Operator (`|>`) for JavaScript

Hijacking grouping-operator `()`

Grouping operator `( )`