# Swiper says it is not compatible with all platforms, and its repo root is named swiper-src > Swiper is a TypeScript touch slider with hardware accelerated transitions, aimed at mobile websites, mobile web apps, and mobile native or hybrid apps. The file is unusually candid about its own scope and unusually quiet about how you consume it, because the repository root package is named swiper-src and the only commands it prints are for developing the library, not for installing it. **nolimits4web/swiper** — Most modern mobile touch slider with hardware accelerated transitions - Repository: https://github.com/nolimits4web/swiper - Website: https://swiperjs.com - Stars: 41,908 · Forks: 9,593 - Language: TypeScript - License: MIT - Published: 2026-08-17 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/nolimits4web-swiper ## The file states outright that Swiper is not compatible with all platforms Read the second paragraph of the description rather than the first. The first sells it as the free and most modern mobile touch slider with hardware accelerated transitions and native behavior. The second says Swiper is not compatible with all platforms, and that it is a modern touch slider focused only on modern apps and platforms to bring the best experience and simplicity. That is an unusually blunt scope statement, and it is placed where nobody can miss it. The stated targets are mobile websites, mobile web apps, and mobile native or hybrid apps, so the positioning is a choice, not a limitation being apologized for. The consequence is real for anyone building for a broad audience. If you need a carousel that degrades on an old browser, or a desktop-first experience with no touch layer, this is the wrong tool by its own account, and finding that out from this paragraph is cheaper than finding it out from a support thread. One warning: the same file also makes superlative claims, calling itself the only slider with 100% RTL support and the most flexible slides layout grid. The caveat and the marketing are both here, and a reader skimming takes away whichever line they hit first. ## The repository root package is named swiper-src, so the repo is not the library The root package.json carries the name `swiper-src` at version 14.3.0, with `type` set to module. The package you actually install is named swiper, which is where the file points for distribution: the npm page at npmjs.org/package/swiper and the jsDelivr page at jsdelivr.com/package/npm/swiper. That split is why the distribution rule is stated as bluntly as it is: on production use files, both JS and CSS, only from the `dist/` folder, because that is where the most stable versions are. The consequence is a specific mistake waiting to happen. Pointing a bundler at a GitHub URL, or aliasing the dependency to the repository root, gets you the source workspace rather than the built library, and you will discover it through missing exports rather than a clear error. If you work from a fork, the same rule applies: the build output is what counts, and the README gives you the two commands that produce it. ``` $ npm install $ npm run build ``` The result lands in `dist/`, and `npm run build:prod` is the production variant of the same step. ## Tree-shaking is backed by a bundle size script that the README never mentions Tree-shakeable is the first feature claimed, worded as only the modules you use being imported into your bundle. The repository takes that seriously enough to enforce it, and the enforcement lives in the scripts rather than in the prose. Two scripts do it: `bundle-size`, which runs node scripts/bundle-size.js, and `bundle-size:update`, which runs the same file with `--update`. Neither appears in the README, which mentions only that modules you use are imported and leaves it there. The rest of the quality gate is visible too. Formatting runs through oxfmt, with `format` and `check-format` as the two entry points, and `validate` runs check-format and type-check in parallel through npm-run-all. The release script runs `npm run validate` before anything else. The consequence is a two-tier reading of the same feature list. As marketing, tree-shaking is one line among many. In the repository it is a number you can regress, which means the claim is falsifiable rather than decorative, and also means the README is not where you would go to confirm it. Nothing in the file tells you what the budget is or where a failing size check stops a release. ## Two demo locations exist and the README names only one of them The demos section says all demos are located in the `./playground` folder, and that you will find Core with HTML and JS, React, and Vue versions there. Three commands follow, one per version. The package.json tells a longer story. There is a `demos` script that serves `./demos/` with vite, which is a different top-level directory from playground. There is also an `element` script pointing at `./playground/element`, a fourth playground that the three-item list in the README does not mention at all. ``` $ npm run core $ npm run react $ npm run vue ``` Each of those scripts is the same shape: run the build, then run vite against the playground directory and the watch script together, killing the others when one exits. The consequence is a documentation drift you can measure. The word all in that sentence is wrong in two directions, because a demo directory outside playground exists and a playground inside it is unnamed. For a reader, that is a small thing. For someone who wants to see how a framework wrapper is wired up, Element is the example they would not find, and the demos directory the README denies exists is the one served by the script called `demos`. ## The icon font build is the only script that needs Python Nearly every script in the package.json starts with node. Build, watch, the playground runners, the bundle size checks, the type tests, the release. The one exception is `build-icons-font`, which runs `python ./scripts/icon-font/generate.py`. So regenerating the icon font needs a Python interpreter on your path, and the Dist and Build section of the README never mentions it. That section covers the development build, the demos, and the production build, and stops there. The consequence is a contributor or packager who hits a missing or stale icon, changes something, and watches the build fail on an interpreter that is not installed, with nothing in the file to tell them the step exists. A Node-only contributor has no way to discover the requirement from the documentation, and the natural place to look, the scripts table, is the one place the README does not reproduce. The practical ordering matters too. Since the icon font is a generated asset rather than something drawn by hand, the question is not whether you will need Python eventually, but whether the icon you need is one you are allowed to add without regenerating the font at all. ## PLAN_V15.md sits in the tree while version 14.3.0 is what ships The top level contains both PLAN_V14.md and PLAN_V15.md, and the shipped version is 14.3.0. So there is a plan document for the next major sitting next to a plan for the current one, checked into the same branch. The README's roadmap section does not mention either file. What it offers instead is two links into the issue tracker: top feature requests and top bugs, both filtered on issues that are open, with the feature request label applied to one query and excluded from the other, both sorted by reactions in descending order, and both described as places to add your own votes using a reaction. The consequence is that the roadmap you can see is a popularity contest rather than a plan. Sorting by reactions rewards whichever request already has visibility, and a genuinely important item with three votes sits below a minor one with three hundred. Meanwhile the actual planning documents are reachable only by browsing the repository tree, which is a place a user evaluating a library rarely looks. The other reading is that the two plan files are internal and not meant for you, which is a defensible choice. If so, the file gives you no way to tell a shipped feature from a committed one, and no way to know whether a v15 will require work from you before you upgrade. ## Three minor versions in 53 days, and a test suite aimed at SSR and cross-realm params The release dates are close together. 14.1.0 landed on 2026-08-06, 14.2.0 on 2026-08-26, and 14.3.0 on 2026-09-28, which is 53 days from first to last. The last push carries the same date as 14.3.0, so the tag and the head of the branch agree. A frequent minor cadence is good news for fixes and a scheduling question for you. Anything you pin will be behind within weeks, and the README's roadmap section, being reaction sorted, will not tell you which of those minors changed behaviour for you. The test scripts are where the real information about edge cases sits, and the README does not mention testing at all. There is a contract test on the dist output, a dist types test, a consumer types test, an element DOM test, a loop warning test, and two that name their problem directly: an ssr-test and a cross-realm-params-test. Server-side rendering and parameter passing across realms are the two things a touch slider built for mobile websites is least obviously equipped for, and the presence of both tests says the maintainers treat them as expected problems. The consequence is that the file's marketing is all touch and hardware acceleration while the unglamorous cases are the ones being guarded in code. If you render on the server or pass parameters in from another realm, you are in the part of Swiper that had to be built deliberately, and you will not learn that here. ## Conclusion Use Swiper if you are building for touch on a modern platform and you want a slider that already ships pagination, navigation, scrollbar, virtual slides, lazy loading, breakpoints and RTL, and you are prepared to read the API documentation rather than the README. Do not reach for it if your targets include old browsers or a non-touch first design, because the file says outright that it is not compatible with all platforms and is focused only on modern apps and platforms. Before you wire it in, check three things: take the library from dist/ rather than from the repository, because the root package is swiper-src; read whether SSR matters to you, since the file never mentions it while the test scripts include an ssr-test and a cross-realm-params-test; and check the release notes, because 14.1.0, 14.2.0 and 14.3.0 all landed inside 53 days. ## FAQ ### how to use swiper The README carries no usage code. It says to use the JS and CSS files from the dist folder in production, lists the features, and links to https://swiperjs.com/get-started, https://swiperjs.com/swiper-api and https://swiperjs.com/demos. The only commands it prints are development ones: `npm install`, `npm run build`, `npm run build:prod`, and `npm run core`, `npm run react` or `npm run vue`. ### how to install swiper The file gives no install command for the package itself. It links to the npm page at npmjs.org/package/swiper, the jsDelivr page, and a get-started page. Worth knowing: the repository root package is named swiper-src, so the repository is the source workspace rather than the published library, and the dist folder holds the files meant for production. ### how to use swiper in react React is one of the playground demos, and `npm run react` runs the build and then runs vite against ./playground/react together with the watch script. The README describes Swiper as library agnostic, requiring no JavaScript library such as jQuery, and does not document a React component API of its own. ### how to use swiper in angular Angular is not covered anywhere in the file. The playgrounds wired up in package.json are core, element, react and vue, and the README names Core, React and Vue. ### What does "swiper" mean? The word overlaps heavily with the cartoon fox from Dora the Explorer and with the Swiper No Swiping meme, and those senses take up most of the questions asked about the name. The library itself is a touch slider with hardware accelerated transitions, intended for mobile websites, mobile web apps, and mobile native or hybrid apps. ## Sources - [Official documentation](https://swiperjs.com) - [Official README](https://github.com/nolimits4web/swiper#readme) - [Project repository](https://github.com/nolimits4web/swiper) - [Release notes](https://github.com/nolimits4web/swiper/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nolimits4web-swiper