Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
GordonFreeman

Webpack bundling Issue

Recommended Posts

Well I have this bundling process:

Starting with coffeescript files being transpiled to their counterpart js files in single directory.

 

So for all those JS files I can include and use them then with:

require "./moduleX.js"

 

Then bundle them with webpack to a single bundle.js

And then I use pug to include the bundle.js into the single HTML file.

 

 

The Problem:

 

When using

import TweenMax from "gsap/TweenMax"

weird strings appear in the HTML outside of script tags and render the whole HTML useless.

 

Such strings are:

"\n\t\t\t *\n\t\t\t * @param {!string} ns The namespace of the class definition, leaving off \"com.greensock.\" as that's assumed. For example, \"TweenLite\" or \"plugins.CSSPlugin\" or \"easing.Back\".\n\t\t\t * @param {!Array.
<string>} dependencies An array of dependencies (described as their namespaces minus \"com.greensock.\" prefix). For example [\"TweenLite\",\"plugins.TweenPlugin\",\"core.Animation\"]\n\t\t\t * @param {!function():Object} func The function that should be called and passed the resolved dependencies which will return the actual class for this definition.\n\t\t\t * @param {boolean=} global If true, the class will be added to the global scope (typically window unless you define a window.GreenSockGlobals object)\n\t\t\t */\n\t\t\tDefinition = function(ns, dependencies, func, global) {\n\t\t\t\tthis.sc = (_defLookup[ns]) ? _defLookup[ns].sc : []; //subclasses\n\t\t\t\t_defLookup[ns] = this;\n\t\t\t\tthis.gsClass = null;\n\t\t\t\tthis.func = func;\n\t\t\t\tvar _classes = [];\n\t\t\t\tthis.check = function(init) {\n\t\t\t\t\tvar i = dependencies.length,\n\t\t\t\t\t\tmissing = i,\n\t\t\t\t\t\tcur, a, n, cl;\n\t\t\t\t\twhile (--i > -1) {\n\t\t\t\t\t\tif ((cur = _defLookup[dependencies[i]] || new Definition(dependencies[i], [])).gsClass) {\n\t\t\t\t\t\t\t_classes[i] = cur.gsClass;\n\t\t\t\t\t\t\tmissing--;\n\t\t\t\t\t\t} else if (init) {\n\t\t\t\t\t\t\tcur.sc.push(this);\n\t\t\t\t\t\t}\n\t\t\t\t\t}\n\t\t\t\t\tif (missing === 0 && func) {\n\t\t\t\t\t\ta = (\"com.greensock.\" + ns).split(\".\");\n\t\t\t\t\t\tn = a.pop();\n\t\t\t\t\t\tcl = _namespace(a.join(\".\"))[n] = this.gsClass = func.apply(func, _classes);\n\n\t\t\t\t\t\t//exports to multiple environments\n\t\t\t\t\t\tif (global) {\n\t\t\t\t\t\t\t_globals[n] = _exports[n] = cl; //provides a way to avoid global namespace pollution. By default, the main classes like TweenLite, Power1, Strong, etc. are added to window unless a GreenSockGlobals is defined. So if you want to have things added to a custom object instead, just do something like window.GreenSockGlobals = {} before loading any GreenSock files. You can even set up an alias like window.GreenSockGlobals = windows.gs = {} so that you can access everything like gs.TweenLite. Also remember that ALL classes are added to the window.com.greensock object (in their respective packages, like com.greensock.easing.Power1, com.greensock.TweenLite, etc.)\n\t\t\t\t\t\t\tif (typeof(module) !== \"undefined\" && module.exports) { //node\n\t\t\t\t\t\t\t\tif (ns === moduleName) {\n\t\t\t\t\t\t\t\t\tmodule.exports = _exports[moduleName] = cl;\n\t\t\t\t\t\t\t\t\t ...

 

I did not manage yet to stop webpack from using eval. Which could be part of the problem.

 

I do have a workaround where I don't use npm, just adding the TweenMax.min.js to the same directory as the other js files and use

TweenMax = require "./TweenMax.min.js"

 

The problem is when using the MorphSVGPlugin it requires the module TweenLite as npm module.

ERROR in ./compiled/js/plugins/MorphSVGPlugin.min.js
Module not found: Error: Can't resolve 'TweenLite' in './compiled/js/plugins'

 

So has anyone an idea on the issue with the thought build process?

 

Or does anybody have an idea how I can get the workaround to also work for the MorphSVGPlugin?

 

Help would be very appreciated :-)

 

Link to post
Share on other sites

Try using

import { TweenMax } from "gsap/TweenMax";

 

Link to post
Share on other sites

Well does produce the same strings in the HTML.

I've tried for all the variations of synthax how to use import which I could find here: https://greensock.com/docs/NPMUsage

 

Currently I'm thinking that for the build process as tought maybe the problem is with pug - as the bundle.js looks  ~"ok" - ignoring all the evals.^^

But it appears to only fail when importing something off gsap.

Link to post
Share on other sites

still did not win the battle.

But probably it is worth adding some information.

 

The Pug appears to behave exactly how it should. As it parses 1:1 the bundle.js where it should inside a script tag in the head.

 

I also noticed that the section where it becomes torn apart is a pretty long comment inside

./node_modules/gsap/TweenLite.js
/**\n\t\t\t * @constructor\n\t\t\t * Defines a GreenSock class, optionally with an array of dependencies that must be instantiated first and passed into the definition.\n\t\t\t * This allows users to load GreenSock JS files in any order even if they have interdependencies (like CSSPlugin extends TweenPlugin which is\n\t\t\t * inside TweenLite.js, but if CSSPlugin is loaded first, it should wait to run its code until TweenLite.js loads and instantiates TweenPlugin\n\t\t\t * and then pass TweenPlugin to CSSPlugin's definition). This is all done automatically and internally.\n\t\t\t *\n\t\t\t * Every definition will be added to a \"com.greensock\" global object (typically window, but if a window.GreenSockGlobals object is found,\n\t\t\t * it will go there as of v1.7). For example, TweenLite will be found at window.com.greensock.TweenLite and since it's a global class that should be available anywhere,\n\t\t\t * it is ALSO referenced at window.TweenLite. However some classes aren't considered global, like the base com.greensock.core.Animation class, so\n\t\t\t * those will only be at the package like window.com.greensock.core.Animation. Again, if you define a GreenSockGlobals object on the window, everything\n\t\t\t * gets tucked neatly inside there instead of on the window directly. This allows you to do advanced things like load multiple versions of GreenSock\n\t\t\t * files and put them into distinct objects (imagine a banner ad uses a newer version but the main site uses an older one). In that case, you could\n\t\t\t * sandbox the banner one like:\n\t\t\t *\n\t\t\t * <script>\n\t\t\t *     var gs = window.GreenSockGlobals = {}; //the newer version we're about to load could now be referenced in a \"gs\" object, like gs.TweenLite.to(...). Use whatever alias you want as long as it's unique, \"gs\" or \"banner\" or whatever.\n\t\t\t * </script>\n\t\t\t * <script src=\"js/greensock/v1.7/TweenMax.js\"></script>\n\t\t\t * <script>\n\t\t\t *     window.GreenSockGlobals = window._gsQueue = window._gsDefine = null; //reset it back to null (along with the special _gsQueue variable) so that the next load of TweenMax affects the window and we can reference things directly like TweenLite.to(...)\n\t\t\t * </script>\n\t\t\t * <script src=\"js/greensock/v1.6/TweenMax.js\"></script>\n\t\t\t * <script>\n\t\t\t *     gs.TweenLite.to(...); //would use v1.7\n\t\t\t *     TweenLite.to(...); //would use v1.6\n\t\t\t * </script>\n\t\t\t *\n\t\t\t * @param {!string} ns The namespace of the class definition, leaving off \"com.greensock.\" as that's assumed. For example, \"TweenLite\" or \"plugins.CSSPlugin\" or \"easing.Back\".\n\t\t\t * @param {!Array.<string>} dependencies An array of dependencies (described as their namespaces minus \"com.greensock.\" prefix). For example [\"TweenLite\",\"plugins.TweenPlugin\",\"core.Animation\"]\n\t\t\t * @param {!function():Object} func The function that should be called and passed the resolved dependencies which will return the actual class for this definition.\n\t\t\t * @param {boolean=} global If true, the class will be added to the global scope (typically window unless you define a window.GreenSockGlobals object)\n\t\t\t */

 

So my current track is the interpretation of the eval(modulecodestring)  where </script> somewhere somehow becomes parsed as HTML which results in a premature script tag close.

 

And now a good Question - if this really appears to be that issue causing the broken HTML. 

How did this work for anybody ever?

 

Probably it would be cool if you remove those comments anyways before package distribution. ;-)

 

 

So when I remove this comment. The HTML stays sane - but still there is a mysterious problem which causes the Error:

Uncaught TypeError: Cannot assign to read only property 'exports' of object '#<Object>'

This error is then caused in the module which imports gsap.

As if the module object somehow becomes... "sterilized" xD

 

So now it appears to be more of a webpack issue.

When being more exact - mixture of import and require - probably now I'm coming a little bit closer :-)

 

 

Link to post
Share on other sites

 

Yess, finally - I had to cleanly remove all require's and that fixed the Webpack issue which was left.

 

Still regarding GSAP the NPM Package and the Webpack import - the problem is that this specified comment line is causing a breakout of the script tag corrupting the whole document.

 

 

Link to post
Share on other sites

Hi @GordonFreeman 

 

I tried to get your attention in another thread, but maybe you didn't get the notification.

 

 

 

3 hours ago, GordonFreeman said:

So my current track is the interpretation of the eval(modulecodestring)  where </script> somewhere somehow becomes parsed as HTML which results in a premature script tag close.

 

Script tags do that for a reason, but why are you even messing with a script tag and eval? That's a huge red flag. You should be using the output of webpack just like a normal JavaScript file.

 

<script src="dist/bundle.js"></script>

 

  • Like 1
Link to post
Share on other sites

hi @OSUblake

No I did not notice any notification^^

 

Well the thing about eval is produced by webpack. I would like to not have the evals just did not find a way around them.

As it probably would mean not to use webpack at all.

 

I liked the Idea to add all the css and js to the HTML - if I have a buildsystem why shouldn't it complete the task? :D

Link to post
Share on other sites
17 hours ago, GordonFreeman said:

Well the thing about eval is produced by webpack. I would like to not have the evals just did not find a way around them.

 

Actually, a script tag does the same thing as eval, and can be just as harmful. That's why browsers won't let you do something like this to create a script.

 

someElement.innerHTML = '<script>alert("HACKED!")</script>'; // FAIL

 

 

That, and the fact that the parser doesn't know where the script tag ends. See how it's done to create a CDN fallback.

 

  window.TweenMax || document.write('<script src="gsap/TweenMax.min.js">\x3C/script>')

 

 

 

  • Like 2
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×