gantt-schedule-timeline-calendar: one TypeScript component for Gantt, timeline and booking UIs

What gantt-schedule-timeline-calendar actually replaces

Most teams that need a Gantt chart start by wiring one library for the bars, another for the resource list, and a third for the date header. gantt-schedule-timeline-calendar, usually shortened to GSTC, ships all three as a single component. The README describes it as an "all-in-one component that you can use in different scenarios" and lists Gantt chart, schedule, timeline, calendar and multimedia timeline editor as target uses.

The audience is narrow in a useful way. The README's own "when to choose" list names reservation systems, booking UIs, resource managers, ERP, MES and APS software. Those are cases where the same row may hold several overlapping items, where rows form collapsible groups, and where the rule for moving a task depends on who is dragging it and what else is already booked. A generic bar chart library gives you none of that. GSTC's selling point is that the rules live in configuration and plugins rather than in a fork of the rendering code.

Config, state and plugins: the mechanism behind the flexibility

The README says you can change "almost everything from DOM tree to logic (without any compilation, without modifying original code - with config, state or plugin)". That sentence describes the architecture: the component is driven by a configuration object and a shared state, and plugins subscribe to that state rather than patching the renderer.

The visible consequences are concrete. Templates and slots let you replace the HTML of individual parts. A background grid accepts your own HTML content. Items can be moved and resized, and the README states you can configure which items are movable at a given moment, which is how you express booking rules. List columns are resizable, sortable and searchable. Time zoom goes down to seconds. Virtual scroll is what the README credits for handling hundreds of thousands of tasks, and the repository ships an examples/big-dataset folder, so that claim has a runnable counterpart rather than only a sentence.

Two design choices are worth flagging. Multiple items in one row is unusual among Gantt libraries and is the reason the booking and reservation use cases fit. The plugin layer is also the extension path for anything the config schema does not cover, which means the learning curve sits in the plugin API, not in the markup.

Installing gantt-schedule-timeline-calendar and running the examples

The README does not give a bare npm install line for consumers. What it does give is the route to the examples, which is the fastest way to see the component running before you wire it into an app. Clone the repository and run the examples script from the root:

git clone https://github.com/neuronetio/gantt-schedule-timeline-calendar.git
cd gantt-schedule-timeline-calendar
npm i
npm run examples

After that command the examples index opens locally, and the repository lists the individual scenarios under examples/, including minimal-item-width, hide-weekends, dependency-lines, movement-plugin, resizing-plugin, big-dataset and multiple-components. Each folder is a self-contained case, so you can copy the configuration of the one closest to your use case instead of reading the whole API surface first.

For framework integration the repository points at separate example repositories rather than embedding the code in the README: react-gantt-schedule-timeline-calendar-example, nextjs-gantt-schedule-timeline-calendar-example, angular-gantt-schedule-timeline-calendar-example and a Vue example, with a Vue 3 Composition API with Vite variant mentioned in the same list. The package name to install is gantt-schedule-timeline-calendar, and the current version in package.json is 3.43.14.

Where GSTC is the wrong tool

The README is promotional, and the gaps are easier to see by reading what it does not say. There is no documented rollback or migration path between major versions, and no upgrade guide in the top-level repository entries beyond CHANGELOG.md. If you pin a version and later need to move, the changelog is the only artefact to work from.

The licence is the bigger practical constraint. The repository carries a LICENSE file, but the licence is not declared as a recognised SPDX identifier, and the feature list ends with "offline license key (after purchase)". A team that needs a permissive open source licence for a commercial product should read LICENSE and the purchase terms before writing any integration code. That is a reading task, not a legal opinion, and it is the first thing to resolve.

There is also a scope mismatch. If your requirement is a read-only chart of twenty tasks with no dragging, no resource rules and no zoom, the configuration and plugin layers are overhead you will pay for and never use. A small timeline component will get you there with less surface area. GSTC earns its complexity when the interaction rules are the hard part.

React-calendar-timeline, Vis-timeline and the difference in approach

The two libraries most often compared with GSTC take different positions on the same problem. React-calendar-timeline is a React component: its API is props and callbacks, and extending it means working inside React's rendering model. GSTC is framework-agnostic and exposes templates, slots and plugins instead, which is why the README can claim the same component works in React, Vue, Angular, Svelte or plain JavaScript projects without a rewrite.

Vis-timeline comes from the vis.js family and is a general timeline and network visualisation toolkit. It is broader in chart types and less opinionated about scheduling semantics. GSTC is narrower: it assumes rows are resources or groups, that items can be moved and resized under rules you define, and that multiple items may share a row. If your data is a timeline of events rather than a set of constrained bookings, vis-timeline's model is a closer fit and you avoid the scheduling machinery.

The practical difference is where customisation happens. With React-calendar-timeline you write React. With GSTC you write configuration and, when that runs out, a plugin against the shared state. The second path keeps framework independence but asks you to learn a project-specific extension API.

Maintenance, licence and what an upgrade costs

The repository is not archived, and the last push was on 2026-06-11. That is the only maintenance signal available here: no release notes were retrieved, so version history has to be read from CHANGELOG.md and package.json, which currently shows 3.43.14. Treat the changelog as the upgrade document, because nothing else in the repository plays that role.

Upgrade cost depends on how far you have gone past configuration. A project that only sets config options has a small surface to re-test. A project with custom plugins is coupled to the state shape those plugins read, and the README does not describe a compatibility policy for that shape. Budget for re-running the examples that match your setup, particularly movement-plugin and resizing-plugin if you rely on drag rules.

On licensing, the feature list mentions an offline licence key after purchase, and the repository's licence is not a standard SPDX identifier. Those two facts together mean the terms are defined outside the source tree. Read LICENSE and the purchase terms yourself; nothing in the README substitutes for that.

Editorial conclusion

Adopt gantt-schedule-timeline-calendar if your scheduling rules are unusual and you need multiple tasks per row, tree groups, second-level zoom and DOM-level customisation in a TypeScript codebase. Do not adopt it if you only need a static read-only chart, or if you cannot accept a licence that the repository does not declare as an SPDX identifier. Before committing, check the LICENSE file, confirm that the offline licence key requirement matches your deployment, and open the examples/big-dataset folder to see how virtual scroll is configured.

Frequently asked questions

Official sources

1. Issues
2. neuronetio/gantt-schedule-timeline-calendar on GitHub
3. Project website
4. README