There are a few other dependencies spread around the repo:

• Collision handling is based on SAT.js
• QuadTree is based on quadtree-js
• me.Object is based on jay-extend

I think the main reason for not using npm is because we don't use anything like commonjs or amd. That's where i think bower would be a bit nicer, for pulling static files. Makes complete sense in that case.

Still if we slowly transition to using es6 modules, i don't see why we shouldn't use NPM at that point.

Most packages in npm don't support the ES6 module pattern, either. But yeah, pretty much what you said.

it's polyfilled through some matter. My point is we would have the ability to require npm dependencies quite easily. Given Olivier mentioned doing it at sometime, it would be the best time to switch to pulling npm vs static files via html/grunt concat ordering.

It's been my experience that packages in npm tend to expect CommonJS+Browserify, or go all in with ES6 import. Meanwhile, we already have our dependency order expectations in line. https://github.com/melonjs/melonJS/blob/85eacab650ad596fb46d0f8290af0544a6e19265/sourceFiles.json

I like the idea, but don't we have custom code on literally each of them ? maybe a good start would be to push back all the changes we did on all respective repos ?

I did similar work on the tutorials; they now have dependency management through npm. For example: https://github.com/melonjs/tutorial-space-invaders/blob/fd5e86b018e60dce53675c5289d9bc77d54100a2/package.json#L7

Install devDependencies with npm, then run that npm script to copy the dependencies to a location that the browser can reach. This allows us to commit only the built dependency files, and not the entire source tree for them.

$ npm install
$ npm run update:deps

I've really enjoyed npm as the dependency manager because it can be locally managed to the solution. That might be because I've used npm a lot.

After using npm exclusively for all dependency management (and even as the build system) it's definitely grown on me. I can't think of a good reason to use Grunt or Gulp... Or bower. :)

The one missing piece is native ES6 module support. It's being worked on right now, but there's still the problem of backward compatibility.

+1 on using npm
-1 for bower, since it's dead

Agreed. Updated title.

@parasyte @obiot @krojew Curious on what you guys think. For building a solution here, i wonder if we need to update the build system. Whether we keep with grunt or w/e, but more importantly do we need to use modules? Or do we just have one file that has the require() vendors, and still do a concat?

Modules will finally give us #212 😄

Fair point. Since we updated to use eslint, i'd love to take it the next step and start leveraging things like webpack, as i find it builds faster, easier to integrate the watch changes workflow as well. I'm more of a mocha + chai fan these days instead of jasmine, though unless updating build system demands it, i'm not rushed to change the testing framework.

Also with ES6 module support coming soon ™️ to all major browsers, I'm not opposed to skipping CommonJS/Webpack and going straight to import/export.

https://github.com/ModuleLoader/es-module-loader :)

Yeah, but native support is coming to every browser already... It's one of those features you can't polyfill. The source has to be transpiled, so you lose native capability altogether.

Would be nice to have the library in npm (where it already is) an compatible at least with ES6 exports:

// src/scenes/MyScene.js

import {LevelDirector, ScreenObject} from "melonjs";

class MyScene extends ScreenObject {
  onResetEvent() {
    LevelDirector.loadLevel("Level_01");
  }
}

export default MyScene;

I have a workaround with webpack, babel and shim-loader which is able to treat a global variable as an export, but I can only use the me centralized object.

You can see an example in the source code of my game prototype: https://github.com/pokettomonstaa/NewBark

It is also necessary that the library does not initialize anything by its own. Right now it is doing it with the preloading screen, etc.

For those of you still reading these comments here : build process has finally be changed to npm, and external dependencies managed through npm and rollup ! I realized i just broke karma with my last commit, but else its working like a charm :)

all done, jasmine fixed, the new build process is a success ! I even added a dependencies badge on the README :P

@parasyte could you add me as a collaborator on npm, looks like I have no right to publish any new version there :)
https://www.npmjs.com/package/melonjs

thanks!

(my username is obiot13)

I added you @obiot

@itsjavi thanks ! finally we have an updated version of melonJS on npm :)

Sorry about that. I would have gotten to it sooner, but I was asleep. :)