Why needs it to be a mix of ESM / CJS imports

[bartcc]

Hi their,

I experienced the same issue reported over here.

 

The solution was to import the Plugin as an CJS Module:

import { ScrollTrigger } from 'gsap/dist/ScrollTrigger';

 

However I would like to understand why some modules CAN be imported as ESM ans some cannot.

Obviously sveltekit environment is able to handle ESM - the following import statements work as expected:

import { gsap } from 'gsap';
import { SplitText } from 'gsap/SplitText';

 

Not sure but I think in FAQ section of the sveltekit homepage this issue is mentioned.

May be someone can shed some light on it.

 

 

 

[OSUblake]

Welcome to the forums @bartcc

 

This is a tricky question to answer because NONE of the imports you posted above are valid if you go by the ES Module spec. This might be a shock to a lot of people who use npm, yarn, etc. but you CANNOT import a module like this in a browser. 

 

import { gsap } from "gsap";

 

The only way you can natively do that is with an import map...

https://github.com/WICG/import-maps#the-basic-idea

 

But good luck with that...

https://caniuse.com/?search=importmap

 

Whatever build tool Svelte is using under the hood, it's using the package.json to determine how to import gsap and related files...

"module": "esm/index.js",
"main": "dist/gsap.js",

 

Unfortunately, package.json only allows you to list a single entry point for the module or main file, so plugins are treated differently. I get the underlying issue of why that happens, usually because of server side rendering (SSR) and node.js compatibility issues, but the bigger question is how can we improve that for the end user?

 

We already provide UMD files, which will work in every environment, but they are not as optimized as our ES Modules. So should we ditch our ESM of being the default in favor of UMD/CJS files?  

 

import { ScrollTrigger } from "gsap/ScrollTrigger"; // default
import { ScrollTrigger } from "gsap/esm/ScrollTrigger"; // smaller, faster, and optimized

 

[bartcc]

Thanks a lot @OSUblake for answering,

first I'd like add one more strange thing I was just observing during build:

 

Notice the mandatory js suffix !

// works
import { SplitText } from 'gsap/dist/SplitText.js';
import { ScrollTrigger } from 'gsap/dist/ScrollTrigger.js';

this throws:

// throws
import { SplitText } from 'gsap/SplitText';
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Library/Server/Web/Data/Sites/svelte-kit-app/node_modules/gsap/SplitText'
// or
import { SplitText } from 'gsap/dist/SplitText';
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Library/Server/Web/Data/Sites/svelte-kit-app/node_modules/gsap/SplitText'

import { ScrollTrigger } from 'gsap/ScrollTrigger'
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Library/Server/Web/Data/Sites/svelte-kit-app/node_modules/gsap/ScrollTrigger'
// or
import { ScrollTrigger } from 'gsap/dist/ScrollTrigger'
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Library/Server/Web/Data/Sites/svelte-kit-app/node_modules/gsap/dist/ScrollTrigger'

*******

...I feel like I would always go for fast and optimized builds. So for me ESMs seem to be the best choice serving as the default import. I wonder if  that would help to resolve all the file paths issues.

 

I fully agree with you, there seem to be lots of compatibilty issues - in particular when SSR is involved. This could also explain the fact that sveltkit/vite might scan just for CJS Modules rather than ESM, hence the unresolved paths

 

Before I switched to sveltekit (and vite as its pre-bundler for dependencies), I was using Webpack or Rollup and never had any major issues during development or production builds, it mostly worked out of the box.

Thanks for providing the https://github.com/WICG/import-maps#the-basic-idea Link - it looks like I will dive into it a bit to gain a bit more of a basic understanding.

 

[OSUblake]

7 hours ago, bartcc said:

first I'd like add one more strange thing I was just observing during build:

 

Notice the mandatory js suffix !

 

Yeah, that's definitely strange, but not something we can really fix as we have no control over how a build system searches for file. Do you know what SvelteKit is using under the hood, like webpack, rollup, vite, etc?

 

7 hours ago, bartcc said:

...I feel like I would always go for fast and optimized builds. So for me ESMs seem to be the best choice serving as the default import. I wonder if  that would help to resolve all the file paths issues.

 

That is currently the default, but it still causes issues in some frameworks. I was only aware of it being a problem in next.js and nuxt.js, but I guess we can add SvelteKit to that list.

 

The only way we could normalize the behavior of the main gsap import and the plugins would be to do what we do with the all.js file, and make that the main import. In case you didn't know, you can import everything from all like this, but I'm assuming it won't work with SvelteKit.

 

import { gsap, ScrollTrigger } from "gsap/all";

 

If we did make the all.js file the default import from gsap, we would have to wait until v4 to do that as it would be a breaking change. The reason we didn't do that for v3 is that at the time tree shaking wasn't a commonly used practice, which could result in a larger bundle for some users, but that's probably a non issue anymore as basically every build tool out there now will do tree shaking.