require('phaser') with Browserify throws error: Error: Cannot find module './Scalar'

[totty90]

I've also got these errors:

• Error: Cannot find module './Scalar'
• Error: Cannot find module './Line'

[the-simian]

@sompylasar Thanks for your input, thusfar!

In case you're curious, the slush scaffold I've been working on is here : https://github.com/the-simian/slush-phaser-webpack

If you, at any point get things working with 2.3.x before I do, we can just get it into the shim and both use it!

[sompylasar]

@the-simian Thanks for pointing to https://github.com/slushjs/slush , haven't heard about it before.

[hayesmaker]

what is the point of the umd definitions in phaser if the thing only works reliably as a globally exported variable anyway?

phaser is broken in requirejs and browserify currently (v2.3.0) either p2 is undefined (requirejs) or cannot find module ../collisions/AABB/ or something similar with Browserify (even with the shim workaround)

[the-simian]

@hayesmaker This shim workaround was for v 2.2.x. I had actually published a shim, and I deprecated it last night, since I got it working otherwise.

You can see a working version of this with the slush-phaser-webpack project. Just install that and scaffold fo a working example.

If you don't want to do that- here's what you can do now

You can also include the correct build criteria yourself:

This can be achieved by simply including the dependencies that are necessary for Phaser to work:

global.PIXI = require('pixi.js');
global.p2 = require('p2');
global.Phaser = require('phaser')

You will need to use the correct versions of both pixi and p2. At the time of this writing, for phaser@2.3.0 uses

{
  "phaser": "2.3.x",
  "pixi.js": "2.x.x"
  "p2": "0.6.x",
}

Also be aware that the npm module pixi is the wrong module, you want pixi.js, the official module

I also agree with you about the module being global. I occasionlly see that when dealing with certain modules expecting a global namespace. Angular, and jQuery for instance are like that. Its the whole reason for browserify-shim, and a lot of that sort of stuff. I am under the impression that Phaser is moving towards supporting amd. I suppose it would be ideal to have something like p2 = p2 || require('modules/p2)` or something similar to make it really work, if the code can't be seen globally. (You'll see a similar situation with pixi.js too).

For now, if you use my scaffold, or follow that tip above - it works.

[hollowdoor]

Did phaser ever work with browserify?

[konsumer]

It worked on my trimmed fork, and it sounds like maybe others got it working.

[nesheroj]

Definitely not out of the box. Various methods can be used as you can see in this very thread. But no official support for any of them, so work might need to be done when phaser is updated (that's why some of the solutions exposed here won't work anymore, including mine)

[the-simian]

@hollowfork I got phaser working in webpack. If you look for slush-phaser-webpack, you can just generate a project. I'm still adding features, but it is stable

[konsumer]

The basic strategy for me was to add require statements in everything for internal/external dependencies in each file, and monkey-patch the global-cached phaser object. I trimmed it because that sort of methodology obviates the need for all the concat/header/footer stuff. I could work on it again, without trimming so much. I just wanted a clean repo to use in other projects.

[hollowdoor]

The easiest would probably be to concat everything from the src folder into a fresh module, but I don't know what order the dependencies are in. Also require checks would have to be transformed into require.resolve. I am wondering if support for envify https://github.com/hughsk/envify would be too much.

[sompylasar]

It's already half-concatenated half-browserified. The easiest is patching via string replacement. The easiest is not the best. The best would be to NOT concat everything, but split and make the sources work in a CommonJS-only environment with NO global variables at all. Then make a build script that glues the modules together for the browser (via browserify or webpack) for someone who does not have a build step in their apps. 30.05.2015 5:25 пользователь "hollowdoor" notifications@github.com написал:

The easiest would probably be to concat everything from the src folder into a fresh module, but I don't know what order the dependencies are in.

— Reply to this email directly or view it on GitHub https://github.com/photonstorm/phaser/issues/1186#issuecomment-106976408 .

[the-simian]

@sompylasar I was doing as you described with the string replacement on the webpack-phaser-shim module (and I had also seen you do too).

I deprecated that with v 2.2.3; If you can stomach a couple modules being attached to global.Module, then it works really well with webpack now. I would assume browserify too, since they are similar in this respect. You might have to use the browserify shim modules; however, to make things work correctly.

[sompylasar]

Everything we did is a workaround for the incomplete CommonJS support. I think this is what should be fixed, not worked around. 30.05.2015 20:03 пользователь "Jesse Harlin" notifications@github.com написал:

@sompylasar https://github.com/sompylasar I was doing as you described with the string replacement on the webpack-phaser-shim module (and I had also seen you do too).

I deprecated that with v 2.2.3; If you can stomach a couple modules being attached to global.Module, then it works really well with webpack now. I would assume browserify too, since they are similar in this respect. You might have to use the browserify shim modules; however, to make things work correctly.

— Reply to this email directly or view it on GitHub https://github.com/photonstorm/phaser/issues/1186#issuecomment-107065384 .

[hollowdoor]

@sompylasar I know what you're saying, but you're speaking of an ideal situation that is being solved in Phaser3. All I want now is an entry point that works. Concatenation with an umd at the end would achieve that best in my opinion. No need to re-engineer the whole thing. And globals don't make me worry all that much. As long as I know which ones are there they won't hurt my feelings.

I haven't found any browserified files in the src folder. The build has them, but I'm not sure where they come from.

[konsumer]

It's totally doable with just browserify, and doesn't require re-engineering, just tracking of internal/external deps, properly. Please see https://github.com/notnullgames/phaser

[the-simian]

@sompylasar , @hollowdoor ...sorry I was unclear.. I mean I am actually not using the shim anymore, as of v 2.2.3, it works with webpack. See full explanation here https://github.com/photonstorm/phaser/issues/1186#issuecomment-104306080

I was going to go make a fork and a PR, but they had already added the code in.

[hollowdoor]

@konsumer interesting. I haven't tried yet, but can specific objects be loaded with your solution safely? Is it just a matter of looking at the errors to see which dependencies are missing? It looks like the ./Phaser file import is everywhere.

I did get it to browserify by the way. It's 787.7 kB minified FYI.

To tell you the truth I'd rather resolve system shims on my own so your version is fine.

Maybe you should publish a scoped phaser to npm. Unless you have, and the readme reads wrong.

I did try to install from the repo, but npm hanged on the install.

[hollowdoor]

@konsumer Oh freakin cool! I just did this with browserify, and babelify. It compiled just fine using your version of phaser.

import BitmapData from 'phaser';

export default class DebugLines extends BitmapData {
    constructor(game, grid, w, h){
        w = w || 800;
        h = h || 600;
        super(game, "debugLine",w, h);

        this.addToWorld(0, 0);
        this.ctx.strokeStyle = '#ff0000';
        this.ctx.lineWidth = 1;
        for(var i=40; i<w; i=i+40){
            this.ctx.beginPath();
            this.ctx.moveTo(i, 0);
            this.ctx.lineTo(i, h);
            this.ctx.stroke();

        }

        for(var j=40; j<h; j=j+40){
            this.ctx.beginPath();
            this.ctx.moveTo(0, j);
            this.ctx.lineTo(w, j);
            this.ctx.stroke();
        }
    }
}

Maybe I have been thinking about phaser modules the wrong way. I still have an glimmer of hope phaser2 gets better module support in this main branch though.

[hollowdoor]

Looks like a spoke too soon because now I'm getting this error. TypeError: this.texture.baseTexture.dirty is not a function. I can't start an issue because this version of Phaser is not official. Maybe I'll try the forums, but I doubt it's a universal problem that will fit the official Phaser release.

[konsumer]

I'm willing to put more work into the official version, especially if the official plan is to replace the concat/header/footer build stuff. Should I fork from dev maybe with a name like commonjs?

[nesheroj]

If I recall correctly, at least in phaser 2.x.x there is no intention to support broserify/webpack. I think I remember some forum thread in which @photonstorm stated that this kind of support wouldn't happen unless other did it, didn't mess with the way he works and didn't break anything.

Phaser 3 is another beast completely and modules support will probably (still nothing set in stone if I'm correct) come as a given as it "will be" (Again, nothing is set in stone AFAIK) written in ES6 / TS 2.0.

I love the work you guys are putting in enabling require-style modules support, but I don't know if its worth it, considering that no current projects could benefit of it as its not yet done 100%, it's a fork, therefore it will need to be synchronised with the original or will be obsolete, and maintenance burden will ever increase.

Again, thanks for the effort. Just leaving my thoughts here.

[nesheroj]

You will need to use the correct versions of both PIXI and p2. At the time of this writing, for phaser@2.3.0 uses

@the-simian If I'm not mistaken, Phaser doesn't use the official PIXI builds OOB, the one included in Phaser is modified (I don't know to which extent). This could be outdated information.

Please accept my apologies if any of this information is incorrect, as I'm writing it based on what I recall.

[hollowdoor]

@konsumer Do you want to add to this branch, or start your own? Are you talking about Phaser2, or 3? Just asking because what nesukun was talking about was confusing me. Perhaps he was speaking to someone else.

Now if the objective is to get the commonjs version into this dev branch I think it can be done if the requires, and exports you have in https://github.com/notnullgames/phaser were somehow templated into the js files using the Gruntfile then that would be a non-breaking solution that would probably work as long as the dependencies line up, and require('phaser') worked as if there was nothing changed at all. I would use this specialty build being the current commonjs doesn't work anyway.

I don't know if I'll contribute, but I am looking at the Phaser source. :)

@nesukun Maybe that's why I got an error about baseTexture.dirty not being a function.

[the-simian]

@nesukun actually I didn't know that, I hadn't gotten any errors yet!

I looked in the source code to match version numbers, and that's where I came up with that particular package. If what you're saying is true I'll need to modify the build.

@hollowdoor I read your issue above. Hadn't run into that yet myself. Post here if you learn more precisely what is up. I'll need to fix my build. Looks like I'll be dipping into the node_modules and grabbing Phaser's "doctored" PIXI files... :(

I will add though, that I did get errors when I did not use the right version number. The version of PIXI in Phaser is way, way behind. Makes sure of that, just to be on the safe side.

[konsumer]

I'm just talking about whatever is in master/dev which according to the package.json in both is 2.X.X. Is 3 somewhere else?

I disagree about hacky templating and grunt to build it. It's not needed at all. A single browserify command can assemble it for everyone without a template, once all the deps are tracked correctly (as in my fork.) The result can be stored in git, if you really need that, but I'd recommend ignoring built files, and just build when needed for CDN/release.

[the-simian]

@konsumer since v 2.3.x I'm not using the hack/shim anymore either,as I mentioned. There is a gulp task, but it simply calls webpack.

[hollowdoor]

@konsumer 3 is somewhere else. About grunt maybe. I was just thinking of pushing back to this main fork, but not changing tons of files by hand. Just to get those requires, and exports like what you have without changing the the files in src. Then let browserify do it's thing just like what can be done with your fork. That way there's only the build script to maintain. I guess templates aren't hacky to me. I've been wrong before. Browserify is kind of hacky by the way. ;)

[hollowdoor]

@the-simian It still doesn't work for me for some reason. You say you're using webpack, or browserify?

[the-simian]

@hollowdoor - webpack, but they should respond similarly. what's breaking? you can give the slush-phaser-webpack a shot, I've been working on that when I can. Might try swapping out webpack with browserify and see what happens

npm install -g slush-phaser-webpack
mkdir browserify-example-slush-phaser
cd browserify-example-slush-phaser
slush phaser-webpack

Then after that, swap out webpack with browserify, see what happens. Id' expect it to basically work.

[konsumer]

Cool, my main point was working CommonJS obviates the need for templates/header/footer/etc. With a CommonJS system, people are free to use whatever build system they like in their own project (webpack, browserify, etc.) If @photonstorm wants to use webpack or any other CommonJS tool for this project's builds (for CDN and release) that really doesn't affect me, as long as the CommonJS is functional. I can pick and choose the files I want in my own project's build.

@hollowdoor the requires & exports need to be in the files in src otherwise it's a mega-hack, in my opinion. I disagree that browserify is hacky. It does 1 thing, really well: build a pile of CommonJS files that are properly formatted into a js file. WIthout templates, using different entry-point files, you can make a million permutations of this project (selecting different physics engines, no physics, leave out whatever you don't need, etc.) This is not possible if a build-step using templates is required. I'm not advocating for browserify anyway, it's just what I use personally in my projects that will depend on phaser, but users can use anything that works with CommonJS (there are a lot of tools for this.)

[nesheroj]

@konsumer, Phaser 3 is in its very early stages, being worked on here: https://github.com/photonstorm/phaser3

There is also some discussion in the forums: http://www.html5gamedevs.com/topic/7949-the-phaser-3-wishlist-thread/ http://www.html5gamedevs.com/topic/13599-reconsidering-building-phaser-3-in-typescript/

[konsumer]

@nesukun ah, cool. thanks!

[hollowdoor]

@konsumer Hm. If you're saying remake Phaser in CommonJs', and just browserify/webpack compile a stand alone Phaser for regular script links, and leave it as modules for the rest of us that sounds good. I was concerned that would be too much of an overhaul for photonstorm, but if it works like usual that's not breaking. I would be all for that personally. I will test it if you want to go ahead with the dev branch. You've already got a proof of concept.

@the-simian I might give slush a look, but I'd still like to have some module consistency in the main fork.

[konsumer]

@hollowdoor Should work the same, and if it'll get used, I'll even do the work. I'm not sure what yer issue is, but it may be upstream or I forgot a require somewhere.

[hollowdoor]

@konsumer It's all good. I'll just watch what you're doing. Large projects can wait for modules. I have several that have gotten out of hand, and modules would help quite a bit. Walls of code lines that make me blurry eyed. If I think I can help on the fork I'll lend a hand.

I think my issue is a missing PIXI method. It's might be in BitmapData. I'll go there if you want me to start an issue.

[the-simian]

@hollowdoor try to require the PIXI that is located in the node_modules of Phaser.

I might give slush a look, but I'd still like to have some module consistency in the main fork.

Slush is just a thing that kicks off gulp processes. I has nothing to do (or not to do) with module consistency. I actually have no idea what you mean by this sentence. The included version of phaser in that generator is based on the main fork, straight off of npm. I am suggesting using it, because you can go from a working build (webpack) to a working build (browserify) without spending too much more time stumbling in the dark. They should treat the modules the same, as I said- but you might need to include browserify-shim (just like if you were shimming angular or jQuery). Yes, it uses gulp, but gulp just callsbrowserify directly. I use gulp because I do a lot of other stuff, like complexity analysis in the generator, and plan on adding even more.

I also agree with @konsumer that browserify is by no means hacky. I use browserify at work (I actually architected our modern build system in that and gulp) and I use webpack in some personal projects. They're both very good, and the differences aren't so great that one is clearly superior to the other. They both build commonJs modules, and get the job done. Browserify might require the browserify-shim plugin in order to handle some global libs. I agree with @Konsumer that a full on CommonJs system for Phaser would be ideal, but thankfully in 2.3.x somone added the exports code at the base of the main file. Yes, its already built- but it does at least work with both browserify and webpack. It did not work in 2.2.x without some bad fixes. I have abandoned those shims, moving forward they aren't necessary. The current version does not break build, even if it is less than ideal.

[hollowdoor]

@the-simian When I use 2.3.x it breaks with a ton of not found require errors. I've read the file with the exports code. I npm installed it, and it's still not compiling with browserify.

The module consistency I was talking about is what the main Phaser has, or doesn't have as the case may be. There are files with relative requires that aren't relative any more in the concatenated module of Phaser. I'm going to try again, but my last try was just a few days ago so I don't foresee any changes. Call it a personal preference, but I'd rather just have something that works. I already have several mostly completed projects. It would not be a problem to transfer those to modules.

The only thing I'm worried about is Rich has expressed dislike for browserify in the html5gamedevs forums. Also photonstorm doesn't want any code changes to mess up their work flow. Another build step for modules is something that would stall a work flow. That's why I was talking with @konsumer about templating the exports in because a global change to modules in the main source would require a build step for the main Phaser devs. They obviously don't want that. Even though I'm sold on CommonJs in Phaser not every one agrees it's the best way.

I'm of the opinion that Phaser was developed with a diverging dependency graph mind set like most older javascript libraries. Modules are a more convergent mindset so while modules can benefit any project in Phaser they would clash a little bit. Especially at the size of the current code base. That's just my opinion. :)

[hollowdoor]

I think I just figured out how to fix it. I feel sort of stupid. There are really only two problems.

1. The requires in the build/phaser.js are browserified versions of modules so they need to be derequired.
2. The check for require('ng.gui') needs to be something else like others said require.resolve('ng.gui').

That would probably get Phaser 95% working with whatever commonjs bundlers there are.

Also I don't understand how PIXI, and p2 are undefined in build/phaser.js when Phaser is a module, and running the same as a script link still works.

BTW. I did derequire phaser.js, and replaced require('ng.gui') with require.resolve('ng.gui'), and it worked. :) I'm too lazy to start a fork.

[konsumer]

The thing about these libs that use this old monolithic use-script-tags approach is that they are fairly easy to convert to CommonJS. Basically they all monkey-patch a primary namespace, and since CommonJS uses a single cached object for requires, you just need the requires at the top. Very easy.

[hollowdoor]

@konsumer Though what you said is true I'm not sure what you're getting at.

BTW there is a pixi.js file in the phaser/dist/modules folder that will fix this error TypeError: this.texture.baseTexture.dirty is not a function if you put that in your fork at https://github.com/notnullgames/phaser instead of var PIXI = require('pixi.js');. I believe dist is created by the grunt file as a prepublish so you have to get phaser/dist/modules/pixi.js from Phaser on npm. Unless you want to put module.exports in all those pixi files in src that is, or run that grunt file manually to get pixi out of it.

[hollowdoor]

@konsumer Oh now I understand. Yeah. I was thinking in terms of the set up that photonstorm has right now. The clash is really a mind set. I had to pick up the pieces of my brain after trying to understand modules back in the day when I was studying python. Now that I do understand them I can't get enough of them. They're almost too easy. I'd like to see them work right in Phaser. Hopefully Phaser3 will do it right. Not that I don't appreciate the work every one is doing on Phaser, and how awesome it is as a game framework.

[photonstorm]

Just to say that I'm preparing 2.4 for release, so if anyone reading this wants or needs to get more changes in to make your module life easier, now is the time to submit PRs. I merged in one tonight that fixed the require issue with NW.

Also just to add that Phaser doesn't use any official release of Pixi any longer. We have diverged too far from the v2 codebase with our own fixes and updates. So if you're doing anything that is requiring Pixi from npm you'll need to change that.

[konsumer]

Is the version use photonstorm/pixi.js? If so, maybe this should be tracked in package.json. You can track it like this:

{
  "dependencies": {
    "pixi.js": "git://github.com/photonstorm/pixi.js"
  }
}

I wonder if that project doesn't have it's own CommonJS issues, though.

[photonstorm]

No it doesn't use that fork any longer. It's a custom version specifically for Phaser, and is part of the core code base. I guess technically I could move it out to its own repo, but it's utterly useless on its own so I'm not sure it's worth the effort.

[sompylasar]

@photonstorm It's more important to make pixi.js a CommonJS-compatible module, and make the rest of the codebase depend on it. Avoid resolving it via global variables, use require. You could then either use relative path require or use it as an npm local path dependency and require by module name.

[photonstorm]

I'm afraid I'm not willing to spend any time doing that. It would require rewriting a good chunk of Pixi v2, which isn't a sensible use of my time.

[nesheroj]

I wonder if just adding a reference to PIXI in the exported Phaser. That way, CJS users can do 'var PIXI = require("phaser").PIXI;' and grab the reference without using globals or having to heavily modify the way Phaser is built.

[photonstorm]

Sounds better to me. If someone wants to go ahead and submit a PR that gets it working I'll happily merge. I reckon I've another couple days of testing and fixing before 2.4 is final.

[hollowdoor]

@photonstorm Did some one put the PIXI reference in? Seems strange that there would be a reference to a global dependency in the dependent.

[rodrimaia]

Updates?