# FullCalendar v7: A Plugin-Based Drag and Drop Calendar for JavaScript

> FullCalendar is an MIT-licensed, TypeScript calendar library whose v7 line splits themes, views and interaction into separate plugins. This review covers how the plugin model works, how to install it from npm, and where the framework connectors and the MIT licence stop.

**fullcalendar/fullcalendar** — Full-sized drag & drop event calendar in JavaScript

- Repository: https://github.com/fullcalendar/fullcalendar
- Website: https://fullcalendar.io
- Stars: 20,658 · Forks: 3,717
- Language: TypeScript
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/fullcalendar-fullcalendar

## What FullCalendar solves, and who it is actually for

FullCalendar renders a full-sized event calendar in the browser and lets users drag and drop events on it. The README describes it as a "Full-sized drag & drop event calendar in JavaScript", and the repository is written in TypeScript under the MIT licence. The intended user is a front-end developer who needs a month, week or day grid embedded in an existing application rather than a hosted scheduling product.

The library is not a backend. It renders events you supply as an array of objects, and the README's own example passes a single object with a title and a start date. Anything beyond that, persistence, permissions, time zone handling on the server, is the application's job. That division is the main reason to pick it: you keep your own data layer and the calendar stays a view.

It is also not a single package. The README lists separate connectors for React, Angular and Vue 3 (plus Vue 2), and the usage example imports plugins for the classic theme, the day grid and interaction separately. Anyone expecting one import that does everything will be surprised by how much of the setup is assembling pieces.

## The plugin architecture: themes, views and interaction are separate imports

The v7 usage example shows the mechanism plainly. You construct a Calendar with a DOM element and an options object, and the plugins array decides what that instance can render. The example passes classicThemePlugin, dayGridPlugin and interactionPlugin. Remove interactionPlugin and the calendar still renders but is not editable; remove dayGridPlugin and there is no month grid to show. The plugins array is the feature switch.

Options sit alongside plugins in the same object. initialView picks the starting view, editable turns on editing, and events supplies the data. The Calendar instance is created first and only painted when render() is called, which matters if you are mounting into a container that is not yet in the document.

Styling is also explicit. The example imports skeleton.css, then the classic theme's theme.css and palette.css. Those are separate files, so a build that drops CSS imports will produce an unstyled calendar rather than an error. That is a real failure mode worth knowing before you debug layout.

The repository itself is a monorepo: package.json is private, named @fullcalendar-monorepos/standard, and the workspace is driven by pnpm with turbo.json at the top level. The published packages live under packages/. The version in the root manifest is 7.1.0, matching the latest release listed for the project.

## Installing FullCalendar from npm and rendering a first calendar

The README gives one install command for the vanilla-JS package. Run it in your project root:

```bash
npm install fullcalendar
```

After that, the README's usage example is the shortest path to something on screen. It imports the Calendar class, three plugins and three stylesheets, then creates and renders the instance:

```js
import { Calendar } from 'fullcalendar'
import classicThemePlugin from 'fullcalendar/themes/classic'
import dayGridPlugin from 'fullcalendar/daygrid'
import interactionPlugin from 'fullcalendar/interaction'

import 'fullcalendar/skeleton.css'
import 'fullcalendar/themes/classic/theme.css'
import 'fullcalendar/themes/classic/palette.css'

const calendarEl = document.getElementById('calendar')
const calendar = new Calendar(calendarEl, {
  plugins: [classicThemePlugin, dayGridPlugin, interactionPlugin],
  initialView: 'timeGridWeek',
  editable: true,
  events: [{ title: 'Meeting', start: new Date() }]
})

calendar.render()
```

You need an element with id="calendar" in your markup for getElementById to find. What you should see is a week view with one event titled Meeting placed at the current time, and it should be draggable because editable is true and interactionPlugin is loaded. If the grid appears unstyled, the three CSS imports are the first thing to check.

If you would rather not wire plugins individually, the README points to the FullCalendar Standard Bundle, which it says is easier to install than individual plugins at the cost of a larger file size, and notes that it works well with a CDN. The README does not give the bundle's package name or a CDN URL, so check the bundle directory in the repository for the exact import path before relying on it.

## Where the MIT licence ends and the premium products begin

The repository states an MIT licence, and package.json repeats it with a copyright line for 2026 Adam Shaw. For the code in this repository that is straightforward: you can use, modify and redistribute it under those terms. Nothing here is legal advice, and the LICENSE.md file is the document that governs.

The confusion worth heading off is that FullCalendar as a product is wider than this repository. The related searches people run include "FullCalendar pricing", "fullcalendar premium" and "fullcalendar scheduler", and the README's link list points to the project website rather than describing paid tiers. This repository covers the standard calendar packages and the framework connectors; it does not contain a scheduler or resource-timeline package, and the README does not document pricing, licence keys or premium entitlements. If your requirement is resource scheduling rather than a day grid, the homepage is the place to resolve whether that is covered.

## Maintenance, release cadence and what upgrading costs you

The last push to the default branch was on 2026-09-05, and the most recent release, v7.1.0, carries the same timestamp. That is recent, and the repository is not archived. The release list shows v7.0.1 and v7.0.2 in July 2026 and v7.1.0 in September, so the v7 line is receiving patch and minor releases rather than sitting still.

Upgrade cost depends on where you are coming from. The related searches include "fullcalendar v7", which suggests people are moving onto this line from earlier majors. The README does not document a migration path, and the changelog is a separate file you have to open yourself. There is no deprecation table in what the project publishes here, so treat the CHANGELOG.md as the authority before bumping a major version.

There is a second cost that is easy to miss: the plugin split means a version bump can change several packages at once. If you import the theme, the day grid and interaction separately, all three need to move together, and the CSS import paths are part of that surface. Pinning exact versions in package.json is cheaper than discovering a mismatched theme after deploy.

If you build from the monorepo rather than installing published packages, note the engine constraint. package.json declares "pnpm": ">=10.15.0", and the README says the repo must be installed with PNPM. The available scripts are build, dev, test, test:dev, lint and clean, with a ci script that runs lint, build and test in sequence. None of that applies to consumers of the published npm package.

## Framework connectors, and when FullCalendar is the wrong choice

The README links dedicated connectors for React, Angular, Vue 3 and Vue 2, each in its own repository. That is the honest answer to the common question of whether FullCalendar works in a given framework: it does, through a wrapper that adapts the vanilla Calendar to the framework's component model, not through the core package. The vanilla install command in the README is for the framework-agnostic package only.

The clearest case where FullCalendar is the wrong tool is a server-rendered application that needs a calendar in the first paint. The library constructs a Calendar against a DOM element and calls render(), and the README's example reaches for document.getElementById. That is browser work. If your stack renders HTML on the server and you want the calendar to exist before JavaScript loads, you are adding a client-side mount regardless of framework.

A second wrong fit is anything that needs scheduling semantics the standard packages do not provide. The README describes a full-sized event calendar with drag and drop; it does not describe resource allocation, capacity planning or recurring-rule editing beyond what your own event data supplies. If those are requirements, you are looking at a different product, and the pricing and premium searches attached to this name are a signal that people arrive expecting more than the MIT repository ships.

A third is a very small footprint. The README itself frames the trade-off: the Standard Bundle is easier to install, but filesize will be larger than picking individual plugins. Either way you are shipping a calendar engine, its theme CSS and its interaction layer. For a read-only list of dates in a sidebar, that is more machinery than the problem needs.

## An alternative approach: build the grid yourself

The realistic alternative for many teams is not another calendar library but a hand-built grid. The difference is where the complexity lives. FullCalendar gives you a Calendar class, a plugins array and an options object, and you spend your time learning its option names and CSS import paths. A custom grid gives you full control of markup and styling, and you spend your time writing date arithmetic, drag hit-testing and view switching.

That trade is worth taking when your calendar is read-only, or when the visual design departs far enough from a standard month grid that you would be fighting the theme anyway. It is a bad trade when you need drag and drop across views, because the interaction layer is the part of FullCalendar that is hardest to reproduce and the part the README demonstrates with interactionPlugin and editable: true.

A middle option the README supports is the Standard Bundle: same library, fewer decisions about which plugins to import, larger output. That is a packaging choice rather than a different architecture, but it is the one the project itself recommends when individual plugins feel like overhead.

## Conclusion

Adopt FullCalendar if you need a month, week or day grid with drag and drop events in vanilla JavaScript or through the React, Angular or Vue 3 connectors, and if you can pin the exact v7.1.0 packages your build resolves. Do not adopt it if you need a scheduling or resource-timeline view: the repository's package list and README cover the standard bundle and plugin packages, and the homepage is where premium products are described. Before committing, verify three things: that your bundler resolves the subpath imports such as fullcalendar/daygrid, that you have added the CSS files the README imports, and that your runtime meets the pnpm >=10.15.0 engine requirement if you build from the monorepo rather than installing the published package.

## FAQ

### Is FullCalendar free to use?

The repository is licensed under MIT and package.json repeats that licence, so the code in this repository is free to use under those terms. The README links to the project website for support and licensing details rather than describing paid tiers, and it does not document pricing or licence keys.

### What is FullCalendar?

It is described in its own README as a "Full-sized drag & drop event calendar in JavaScript", written in TypeScript and distributed under the MIT licence. It renders events you supply and lets users drag and drop them, rather than providing a hosted scheduling backend.

### Can I use FullCalendar in React?

The README lists a React connector in a separate repository, alongside connectors for Angular, Vue 3 and Vue 2. The npm install command shown in the README is for the vanilla-JS package, so React users go through the connector rather than the core package alone.

### How to install FullCalendar?

The README gives one command, npm install fullcalendar, for the vanilla-JS package. After that you import the Calendar class, the plugins you need and the stylesheets, then create the instance and call render(), as shown in the README's usage example.

### Is FullCalendar a library?

Yes. It ships as npm packages you import into your own build, with a Calendar class, a plugins array and an options object, and the README installs it with npm install fullcalendar. The connectors for React, Angular and Vue are separate packages rather than a hosted service.

## Sources

- [fullcalendar/fullcalendar on GitHub](https://github.com/fullcalendar/fullcalendar)
- [License: MIT](https://github.com/fullcalendar/fullcalendar/blob/main/LICENSE)
- [Project website](https://fullcalendar.io)
- [README](https://github.com/fullcalendar/fullcalendar/blob/main/README.md)
- [Releases](https://github.com/fullcalendar/fullcalendar/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fullcalendar-fullcalendar