JSPM registry entry for Parse about parse-sdk-js

[andrewimm]

Hey @typhonrt, let me first say I'm really excited to hear that you're working on a Parse+Backbone binding.
I'm not familiar with JSPM, so you'll have to forgive me as I try to wrap my head around the problems here. Sounds like you'd like to add Parse to JSPM, since that's what your project uses for dependency management. I'm looking at the package.json overrides that JSPM allows, and it looks like we could configure things to only include dist/ or dist/parse.js, either through this repository's package.json or through JSPM's override repository (my preference). Would something like this work for you? We'd be happy to submit Parse to JSPM with the appropriate configuration.

[typhonrt]

Re: JSPM / SystemJS it's a solution that is just shy of the limelight right now in comparison with Webpack / Browserify, etc. I think it's going to be rather big in the coming years as there is a lot of power available and very active development. It can pull in dependencies directly from NPM or Github and more or less resolve things intelligently. When I pull in the Parse NPM package it does pull in far too much including all dependencies for Node / React-native found in package.json.

Another option is pulling in the source code of the Parse SDK directly from the Github repo potentially, but there are issues with just 9 files in the SDK which combine ES6 imports and CJS exports with some require statements peppered about (Parse.js being one of these files). I just finished a little experiment by copying all of the Parse JS SDK from the Github repo into my framework / production app and converted these problem files to pure ES6 by using ES6 export semantics:
Parse.js
CoreManager.js
TaskQueue.js
StorageController.browser.js
StorageController.default.js
StorageController.react-native.js
Storage.js
InstallationController.js
RestController.js

Only a few additional changes were necessary. IE changing any require statements in Parse.js to import semantics and in a few other files as necessary.

Also I needed to comment out use of process.env, a Node runtime variable, in the following files:
Parse.js
Storage.js
RestController.js

I added window.Parse = Parse; in Parse.js as it's needed for Underscore to access Parse in template usage. One can defensively add it only if "window" exists.

I've not seen this mixed ES6 / CJS style used before; I guess Browserify might support it? If the whole Parse SDK can be written in pure ES6 that is best solution IMHO. It's actually not a big change per se.

So in addition to making the Parse SDK pure ES6 getting rid of the CJS exports it should be possible to create a facade for process.env creating one more file / module that sets the runtime environment via defensively checking for the existence of "process.env"; then import this facade to check in the runtime.

Also one could easily add an existence check for "window" in Parse.js and only set window.Parse = Parse; when it exists.

So, after these changes I was able to run my ES6 Backbone port directly against the unbundled Parse SDK source code in SystemJS. I also was able to use the SystemJS Builder to create my own transpiled bundled version of Parse, Parse + my Backbone fork and this worked with no problems to create a bundled version directly from SystemJS / no Browserify needed.

I do think the best way forward is a slight refactoring of the Parse SDK (took me 30 minutes) to make it pure ES6 and the other minor change to make a facade around runtime checks for "process.env".

I'll be able to pull in the Github repo directly with JSPM and all will be good! :D

As an aside regarding my efforts I've actually created a modern ES6 / Backbone framework for web app dev and it depends on SystemJS / JSPM for runtime / package management, so a little bigger than a one off project. I'll be releasing the web framework soon for others to use. An example of the power I'm moving towards providing a terminal GUI (w/ Blessed) allowing a GUI over SystemJS / JSPM for ease of use and monitoring deployments of one or more web apps to various staging / production servers without messing around with devs needing to know anything about Gulp or SystemJS. I've been using Parse as the backend to accelerate development and also have a product based on these efforts launching soon. So, I'm at this full time and trying to resolve the Parse + Backbone issue right now.

[andrewimm]

Cool, makes sense.

So I'd encourage you to stay away from compiling against the ES6 src/ directly. Our codebase is designed to fork at build time to support different functionality across multiple platforms, and using it in an uncompiled form will definitely lead to issues (this is where the process.env references come in). The reason we have mixed import/CJS modules is because our codebase is designed to be compiled down through Babel, after which everything becomes a CJS require.

For now, I'm wary of attaching the Parse module to the window. Many people wish to use modules to avoid namespace pollution, and I'd like to respect that. Developers who continue to just import the pre-built browser SDK as a <script> tag will get it as a top-level object. This functionality seems extremely application-specific, and any module system gives your app access to the things it exports.

It seems to me that the best approach for getting Parse into JSPM is to fetch it from npm, and use a registry override to limit the files it pulls in. The only open question is whether it's better to fetch the lib/browser directory (separate ES5 files with require() statements), or dist/parse-latest.js (pre-compiled single file).

[typhonrt]

So I'd encourage you to stay away from compiling against the ES6 src/ directly.

As things go I also need to create a combined ES5 bundle for supporting Parse+Backbone. That means dealing with your source and build patterns. As stated because the JS Parse SDK is not pure ES6 it causes general problems unless one adopts Browserify and only wants to create a bundled SDK.

I'm attempting to provide several artifacts or configurations including a pure unbundled ES6 Backbone fork, unbundled ES6 Backbone + bundled Parse, and a combined ES5 Parse + Backbone bundle.

Our codebase is designed to fork at build time to support different functionality across multiple platforms and using it in an uncompiled form will definitely lead to issues (this is where the process.env references come in)

Yeah, I'm aware of that.. I'm going to do a few more experiments to see if I can get my ES6 Backbone fork to play nice with Browerify + Parse and at the same time SystemJS.

I still think the mixed import / CJS export is unnecessary as Babel should have no problems transpiling pure ES6 to CJS. Your code will be easier to read without this mixed format. I haven't seen any other project do this.

For now, I'm wary of attaching the Parse module to the window. Many people wish to use modules to avoid namespace pollution, and I'd like to respect that.

I agree on this.. After all I was just using some example code copied from the Parse web site which is now out of date for my production app. In my case it was one _ template in my production app entering the user name directly from Parse.User and this can easily be changed to feed parsed json to the template from the Backbone.View itself. If the developer wants to add parse to the global namespace then they can easily do that themselves.

[andrewimm]

You can compile ES6 projects against the ES5 code of the SDK. I've done this a number of times with no problems. Assuming you're using Babel in the chain, it should have no issue.

Here's the reason we don't consistently use ES6 imports: they're hoisted, and they can't be placed in blocks. The biggest reason we gate logic for different platforms is that non-browser environments need to require() browser-like APIs. If we need to gate these, we need to use require.
The statements in Parse.js are simply there for clean code -- I could get rid of those whenever, with no issue, but you won't be able to eliminate the other statements gated in if statements. This is why I'd encourage compiling against the ES5 version, it'll be consistent.

[typhonrt]

It's good to know the reasons behind the mixed format / re require in blocks due to ES6 imports being hoisted.

For my use case for the framework I'm creating ES6 backbone against the ES5 Parse bundle is no problem as long as we can resolve the dist directory and any JSPM package constraints to limit only importing the dist directory from the NPM package.

Regarding the ES5 Parse + Backbone combined bundle that goal is to be a "good citizen" with the rest of the world and providing everyone a replacement for the non-continued Parse functionality. Not everyone will be able to use the ES6 Backbone fork.

[typhonrt]

I've confirmed that I can create the transpiled ES5 Backbone w/ Parse bundle from SystemJS. I think we're good to go with JSPM registry and the JSPM package override.

It looks like all you have to do is submit a pull request of the JSPM registry:
https://github.com/jspm/registry

In registry.json add:

"parse": "npm:parse",

And in https://github.com/jspm/registry/tree/master/package-overrides/npm create a new json override file "[email protected]" with the following contents:

{ 
   "dependencies": {}, 
   "devDependencies": {}, 
   "directories": { "lib": "dist" } 
   "files": ["dist/"], 
   "main": "parse-latest.js", 
} 

FWIW Previously I was loading the UMD Parse bundle as a global in SystemJS which is why I still had access to window.Parse with 1.6 since I didn't provide an explicit module format. So yeah... no window.Parse needed. ;) Installing the Parse NPM package with the above override automatically sets the format to CJS.

[andrewimm]

Agreed, I think that's the only step necessary. I'll try to get that PR into their registry when we release 1.6.5 in the next day or so (no point in doing it for a version that will immediately be outdated)

[typhonrt]

Sounds good. From my understanding the version number as part of the file in the JSPM registry uses the highest number for the package specified, so if you put in 1.6.4 and that is the only one it will work for 1.6.4 and all greater version numbers. IE you don't have to continually update the registry for each release of Parse. Thanks for taking a look. I figure if you get the commit in that it will be a reminder of where Parse is getting consumed in different module systems.

[typhonrt]

Just checking in as I see Parse JS 1.6.5 SDK has been released to NPM. As mentioned it seems good for you to submit the update to the JSPM registry as a reminder in your Github account in regard to where Parse is being consumed. I'm more or less done with Parse / Backbone support and would like to get my repos up on Github, but need the registry JSPM entry in before I can make things public as I use SystemJS to build the various release / dist bundles or of course for folks just pulling in the ES6 source code directly via JSPM. Thanks...

Also in looking at pull requests from the JSPM registry it looks like the override JSON file needs to be alphabetical order:

{ 
   "dependencies": {}, 
   "devDependencies": {}, 
   "directories": { "lib": "dist" } 
   "files": ["dist/"], 
   "main": "parse-latest.js", 
}

[andrewimm]

PR here: jspm/registry#609

[typhonrt]

Thanks for getting to this today! Looks like Guy just replied and you need to remove "directories" and make "main": "dist/parse-latest.js"... I'll test real quick here to make sure.

[typhonrt]

Hi @andrewimm... I've tested the below override and I think it satisfies Guy's request.

{ 
   "dependencies": {}, 
   "devDependencies": {}, 
   "files": ["dist/", "LICENSE", "PATENTS"], 
   "main": "dist/parse-latest.js" 
} 

[typhonrt]

I think we can close this for now... @andrewimm The Backbone / Parse repos are located here.

• https://github.com/typhonjs-parse/backbone-parse-es6

I'm finishing up more documentation and the proverbial TODOs demo app this weekend w/ a ton of documentation on how to use SystemJS / JSPM + the bundled versions of Backbone-Parse-ES6 + ESLint, ESDoc, Travis CI, Gulp and a bunch of other modern practices. It'd be great to get a post or even guest post if you guys are down on the Parse blog later next week. Perhaps drop me an email at [email protected] to coordinate. Cheers...