line-bot-sdk-nodejs, and how a vendor SDK keeps up with its own API

What the SDK is, and what it is generated from

The LINE Messaging API SDK for Node.js makes it easy to develop bots using the LINE Messaging API, and the claim is that you can create a sample bot within minutes.

What makes this SDK different from a hand written wrapper is visible in the repository layout. There is a line-openapi directory, which is the API specification, a generator directory, and a generate-code.py script at the top level. The client types and the request methods are therefore produced from the specification rather than typed by hand, which is the only way an SDK for a large and changing API stays accurate.

That decision has an obvious upside and an obvious cost. The upside is that a new API feature appears in the SDK as a generated type, correctly shaped, and a webhook event arrives as a typed payload rather than as an untyped object. The cost is that the SDK's surface is the API's surface, so it is large, and a developer reading the type definitions is reading a machine generated description of a messaging protocol rather than a curated one.

The audience is developers building LINE bots, and the documentation pointer is the official API documentation, in English and Japanese, with the SDK's own documentation on its GitHub Pages site. The project also links the Messaging API FAQ and the news feed, which is where platform side changes are announced.

The licence is Apache-2.0, and the copyright is held by LINE Corp, so the code that builds the bots comes from the same organisation that runs the platform.

Installation, and the Node 22 floor

The requirements are stated in one line: Node.js 22 or higher. The package manifest agrees, with an engines field of node >=22, and the type field of module, so the package is ESM first.

The install is published on npm under a scoped name, and the project shows the three package managers it supports.

$ npm install @line/bot-sdk

$ yarn add @line/bot-sdk

$ pnpm add @line/bot-sdk

The scoped name matters for a bot project, because the credential you need to talk to the API is tied to a LINE channel and a bot, and the SDK is the piece that holds the channel secret and access token handling.

The Node 22 requirement is the current kind of requirement, where the floor is a moving target that a project bumps as the ecosystem moves. For a team on an older runtime this is a hard stop rather than a warning, and it is worth checking against whatever else is in the same deployment, since a bot is often the only part of a stack that still runs on an old Node version.

The package is published from a build that produces both module formats, and the exports map resolves each of them to its own type declarations, which is the arrangement that lets a TypeScript project using either module resolution mode get correct types.

Dual output: ESM, CommonJS and a type file for each

The exports map in the package manifest is worth reading closely, because it is the part of a package that causes friction when it is wrong.

The root export has an import condition with its own types file and the ESM build, a require condition with its own types file and the CommonJS build, and a default that points at the CommonJS build. There is also an explicit export for package.json, which is a small detail that lets tooling read the manifest through the same resolution rules.

The build script is where that structure comes from.

npm run build

It runs a format check, cleans the dist directory, compiles twice, once with the ESM configuration and once with the CommonJS configuration, and then writes a package.json containing the type commonjs into dist/cjs so that Node treats that directory as CommonJS even though the root package is a module. That single line is the trick that makes dual publishing work without a bundler.

There are two type declaration files as well, one per condition, so a consumer using import and a consumer using require each get the types that match the code they are loading.

The published files list includes dist and lib, and excludes the test directories in both, so the package ships the library and the built output without the fixtures. The sideEffects field is false, which tells a bundler it can drop the package entirely if none of its exports are used, a small but real win for an application that only needs the client in one route.

Six examples, and four ways to write the same echo bot

The examples directory is the fastest way to see what the SDK looks like in practice, and its shape is deliberate.

There are four echo bot examples, and they differ in how the project is set up rather than in what the bot does. There is echo-bot, echo-bot-esm, echo-bot-ts-cjs and echo-bot-ts-esm. So the same trivial bot is provided as plain JavaScript, as JavaScript with ES modules, and as TypeScript in each of the two module modes.

That is a deliberate choice and it is worth reading as a statement about the package. An SDK that supports ESM and CommonJS, and that ships types for both, has to prove that all four combinations work, because the failure mode of a dual package is a consumer whose require works and whose import does not. Shipping the four examples is the cheapest way to keep that honest.

The other two examples are more interesting. There is kitchensink, which is the traditional name for a sample that exercises every feature of a library, and there is rich-menu, which is a sample for one specific API area.

The rich-menu example is the one to point a new user at, because the rich menu is a visible part of the LINE product, the part users actually see, and a sample for it shows both the client call and the payload shape in a way that a type definition does not.

The documentation site is built with VitePress, with a development server, a build and a preview script, and the API reference is generated with TypeDoc into markdown, excluding private members, which is a reasonable arrangement for a generated SDK reference.

The quality gate, and the release notes that name API features

The scripts in the package manifest show how the project checks itself, and it is a stricter gate than most SDKs run.

The test script runs the formatter, then the type check, then the build, and only then the test suite with vitest, so a formatting or typing failure stops the run before a single test executes. The build itself starts with a format check, which means an unformatted file cannot be published.

There is a separate coverage script that runs vitest with coverage, and a checkAll script that runs a shell script in the scripts directory, which is presumably the aggregate of everything.

Two of the checks are unusual and worth naming. There is a publint check, which validates that the package manifest is correct for publishing, and there is an attw check that runs against the packed tarball, which is the Are the Types Wrong tool. That tool verifies that the type declarations resolve the way a consumer's TypeScript configuration will actually resolve them, across module modes and resolution settings, which is precisely the class of bug that a dual package gets wrong.

The release line is where the SDK's relationship to the platform becomes visible. v11.3.0 supports templated LINE notification messages and custom aggregation units. v11.2.0 supports the Message Edited Webhook. v11.1.0 supports the rich menu summary API and the daily report API.

Each release names the API feature it adds, and each names a feature, not a bug fix, which is the clearest possible signal of how a platform SDK is versioned. The last push was on 2026-10-19, so the SDK is being updated as the platform moves.

Semantic versioning, and the exception the project reserves

The project says it respects semantic versioning, and then states an exception in a sentence worth reading twice.

However, if a feature that was publicly released is discontinued for business reasons and becomes completely unusable, the project will release changes as a patch release.

That is an unusual and honest commitment, and it is worth understanding what it means. A patch release normally means a bug fix that does not break anything. Here it means a feature can disappear in a version that does not signal a break, because the platform operator decided the feature is going away for commercial reasons rather than because the SDK changed the API badly.

For a bot developer, the practical consequence is that a patch bump in the SDK can remove a capability. The mitigation is not technical, it is procedural: read the release notes when you bump, and if your bot depends on a feature that the platform might retire, keep the integration behind your own abstraction so it can be swapped out.

The rest of the project housekeeping is conventional and tidy. There is a CODE_OF_CONDUCT.md, a CONTRIBUTING.md that contributors are asked to read first, a renovate.json5 for automated dependency updates, an .editorconfig, a prettier configuration, a .npmrc, a .gitmodules, and a LICENSE carrying the Apache 2.0 text with the LINE Corp copyright.

The repository is not archived, and the three most recent releases are v11.3.0 from 2026-09-29, v11.2.0 from 2026-07-07 and v11.1.0 from 2026-07-01.

Editorial conclusion

Adopt @line/bot-sdk if you are building a LINE bot and want the request and response types to match the Messaging API exactly, including the newer webhook and templated message features, rather than hand writing the payloads. Do not adopt it if you only need to send a message, since a plain HTTP call will do that, and do not assume a version number tells you which API features are supported, because the mapping between an SDK release and an API feature is what the release notes are for. Before you commit, check that the SDK version you pin includes the webhook events your bot depends on, and read the versioning note about features that get discontinued for business reasons, because the project reserves the right to ship those as patch releases.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. line/line-bot-sdk-nodejs on GitHub
3. Project website
4. README
5. Releases