3.14.0 – TypeScript case-sensitivity issue with single-word module imports

[OversensitiveCat]

After upgrading from 3.13.0 to 3.14.2, importing certain GSAP modules with a single-word name (e.g. Draggable, Observer) causes TypeScript to report a case-sensitivity error on case-sensitive file systems (macOS/Linux):

import { Draggable } from 'gsap/Draggable'

This results in the following error:

File name ‘…/node_modules/gsap/types/Draggable.d.ts' differs from already included file name ‘…/node_modules/gsap/types/draggable.d.ts' only in casing.

The error disappears when importing the module from the src path:

import { Draggable } from 'gsap/src/Draggable'

or by updating the reference in index.d.ts:

<reference path="Draggable.d.ts"/>

I don’t have extensive experience with this kind of TypeScript issue, so I’m not sure whether this is a problem on GSAP’s side or something related to my TypeScript configuration.

[jackdoyle]

I'm pretty confident that's not an issue with GSAP but perhaps I'm missing something.

The usual culprits for that error are:

---

1. Two different imports/paths reference the same thing with different casing
   e.g. some code (or a dependency) imports gsap/Draggable while another imports gsap/draggable. On a case-insensitive FS those resolve to the “same” thing at runtime, but TypeScript still tracks filenames distinctly and flags it. I think this is the most likely culprit in your case.

2. Both files exist in the installed package
   For example, the user ends up with both:

node_modules/gsap/types/Draggable.d.ts
node_modules/gsap/types/draggable.d.ts

This can happen if a file was renamed only by casing, and the installer didn’t fully clean the old one on a case-insensitive FS. TS then sees both and throws TS1149. But I just checked and I don't see any of the TypeScript definition files that were renamed, so unless you did that on your end I doubt it's the issue.

3. Editor / TS server caching after a casing-only rename
   Less common for node_modules, but it’s a known trigger in general: a casing-only rename can leave stale state until the TS server / IDE restarts.

---

I'd recommend starting by doing a clean install of GSAP. Go into node_modules and DELETE the whole "gsap" directory. Then npm install it again from the terminal. Does that solve it?

If not, search your own codebase for inconsistencies in your imports. Grep for both:

gsap/Draggable
gsap/draggable

And then make them consistent. I'd import Draggable, for example, because that's what the actual Draggable file is (uppercase first letter).

I hope that helps!

[OversensitiveCat]

Thanks for your help!

Unfortunately, I've already tried and checked all of these.

I can reproduce the issue in a completely fresh Nuxt or Vite project with no custom configuration. The error disappears immediately when I downgrade GSAP to version 3.13.0.

[jackdoyle]

Hm, I just created a fresh Nuxt project and it worked perfectly. No problems or errors with GSAP 3.14.2. We haven't heard about any issues like this from anyone else either, so it sure seems like some kind of odd issue on your particular system. Are you absolutely sure that you don't have mixed casing in any of your imports? And do you see any evidence in your file system of files in GSAP's /types/ directory that show mixed casing? And you did a complete uninstall of GSAP on your system, cleared the npm cache and re-installed GSAP?

[rhernandog]

Hi @OversensitiveCat

I tried different setups using Typescript and GSAP 3.14.2 and I haven't been able to reproduce this with these imports:

import gsap from "gsap";
import { Draggable } from "gsap/Draggable";

gsap.registerPlugin(Draggable);

I tried with Vue using Vite, Nuxt, React using Vite and NextJS, all of them with Typescript setup and I haven't been able to reproduce this, so there must be something else in your setup causing this. I tried in Ubuntu 22 and MacOS.

Could you provide a minimal setup that reproduces the error so we can test it

Best,
Rodrigo.

[OversensitiveCat]

This is my setup :

Operating system	macOS 25.1.0
CPU	Apple M2 Max (12 cores)
Node.js version	v24.12.0
nuxt/cli version	3.31.2
Package manager	npm@11.6.2
Nuxt version	4.2.2
Nitro version	2.12.9
Builder	vite@7.3.0
Config	compatibilityDate, devtools
Modules	-

Here are the links of two repositories where I have encountered this issue:

https://github.com/OversensitiveCat/nuxt-gsap-test

https://github.com/OversensitiveCat/vite-gsap-test

Thanks again for your help. I'm investigating to see if I can find something in my environment that could be causing this issue!

[matteoditucci-air-up]

Hi folks, @dkouvdis and I have the same issue as @OversensitiveCat.

We are on macOs too, but I think the issue might be related to git: https://dev.to/iediong/fixing-file-renaming-issues-in-git-handling-case-sensitivity-and-coreignorecase-1mf6#:~:text=By%20default%2C%20it's%20set%20based,Git%20treats%20files%20like%20File.

Docs for the mentioned git configuration: https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreignoreCase

The tidbit is: we try to import a file called Draggable with uppercase D, but the filesystem file name is draggable with lowercase D

[rhernandog]

Hi @OversensitiveCat

I cloned, installed and ran both packages without any issues, everything worked as expected and I didn't ran into any console errors/warnings in the browser or any other issues in the terminal as well. Again this on a Mac and an Ubuntu 22 machine. That clearly tells me that there is something else wrong in your setup that could be causing this, perhaps a global TS config or flag that is triggering this 🤷

Also is worth noticing that your Nuxt project doesn't have any of the recommended typescript setups you can find in the docs for versions 3.x and 4.x of Nuxt:
https://nuxt.com/docs/3.x/guide/concepts/typescript
https://nuxt.com/docs/4.x/guide/concepts/typescript

I installed once again Nuxt in both of my machines and I can't seem to replicate this.

Sorry I can't be of more assistance in this 😞

[rhernandog]

Hi @matteoditucci-air-up

As far as I know the installation and export/import process doesn't change the case of the files. GSAP is used very widely on the web, with a good percentage of the developers using Typescript for their projects, and if this was the case we would have hundreds, if not thousands, of issues and threads in our forums with reporting this issue.

It would be great if you could provide a small repo so we can reproduce the problem, because I already installed and created several projects since yesterday, without being able to replicate it.

[jackdoyle]

@matteoditucci-air-up @OversensitiveCat it sounds like you think we changed the capitalization of some files in the package, but we didn't. Feel free to check Github repo as well as the historic packages on NPM. I can't see any changes to capitalization at all which is why I'm confused about the error you're running into. Can you find any evidence of capitalization changes between 3.13.0 and 3.14.x? I just triple-checked Draggable and it's identical between those versions...right? Same goes for the TypeScript definitions file. Maybe I'm missing something obvious, but nobody here can reproduce the issue you're running into even with a clean install from NPM.

[OversensitiveCat]

Hi @rhernandog @jackdoyle, thanks for your feedback!

I just tried on a different computer with no specific configuration, and encountered the same issue.

│ │ Operating system macOS 25.1.0 │
│ │ CPU Apple M1 (8 cores) │
│ │ Node.js version v23.10.0 │
│ │ Package manager npm 10.9.2 │

@rhernandog I don't think the typescript setup you mentioned is mandatory for a nuxt project, it's more about type-checking than a typescript configuration that could solve this problem. In any case, this doesn't change anything, as I have this configuration in the project where I originally encountered the issue.

@jackdoyle I also checked the differences between versions 3.13.0 and 3.14.x, but I couldn't find anything that could cause the issue. I don't think you changed the capitalisation of any files; I'm just confused.

[wietekepots-arch]

Hey there! 👋

Just wanted to add some context here — this is a real issue affecting TypeScript users on macOS/Windows (case-insensitive filesystems), and it's not a misconfiguration on the user's side. I understand you didn't change the casing on those files — this is a subtle issue that likely surfaced in 3.14 due to other changes in the package, not the type files themselves.

The fix is minimal:

• Rename three .d.ts files to match JS casing
• Update references in index.d.ts
• Add // @ts-nocheck to VelocityTracker.js

No breaking changes. I've put together a PR with the fix: #638

Happy to discuss! 🙂

[jackdoyle]

@wietekepots-arch thanks for your suggestions! However...

1. We didn't change any of those file names in 3.14.x; what "...other changes in the package" caused this to suddenly become an issue?
2. Why not just set "skipLibCheck": true in your tsconfig.json file? From what I can tell, that's the recommended TypeScript solution rather than setting // @ts-nocheck
3. Why are you suggesting only changing 3 of the file names rather than all of them in the /types/ directory? What you're suggesting would break convention - from what I've read, kebab-case is recommended (and that's exactly what we used). Changing only 3 of the file names to use Pascal-case would mean that there'd be a mix of Pascal and kebab.

After further research, I suspect that the root of this issue is that TypeScript 5.0+ infers a file path from the module name, so it's not due to any change in GSAP but rather you may have upgraded to a newer version of TypeScript that behaves differently. Apparently the standard practice is for users like you to simply add "skipLibCheck": true to your tsconfig.json file. Does that resolve things on your end?

[wietekepots-arch]

Hey @jackdoyle 👋

Thanks for digging into this!

I did some research too and found the likely root cause: the new exports field added in 3.14's package.json

"exports": {
    "./*": {
        "types": "./types/*.d.ts",
        ...
    }
}

This explicit types mapping changed how TypeScript resolves type definitions. In 3.13, without the exports map, TypeScript used a different resolution path that didn't expose the casing conflict. So while TypeScript 5+ may be stricter about casing, the trigger was the new exports configuration.

The original reporter and I both have skipLibCheck: true and still hit TS1149 — this error is a module resolution issue, not a type-checking issue, so skipLibCheck doesn't prevent it. skipLibCheck also doesn't affect .js files — only .d.ts files. So users with checkJs: true will still hit errors in VelocityTracker.js.
Regarding the scope of the fix: Only 3 files cause TS1149 (Draggable, Flip, Observer) because their filenames differ from their module declarations only by case. Other plugins use kebab-case filenames (scroll-trigger.d.ts vs ScrollTrigger), which don't conflict.

For consistency, I'm happy to rename all type files to PascalCase to match their JS counterparts. Would you like me to include that in the PR?