Support for module loading

[matthewtoast]

Most developers will expect to be able to do this:

// In jon-doe/example/example.js

var _ = require('lodash');

FamousFramework.scene('jon-doe:example', {
    // etc.    
});

Although we don't restrict _against_using require etc., we don't currently have automatic support for it through our build process, meaning that the bundles generated by our build process won't actually have the required packages loaded in.

The current workaround

The current workaround is to pre-bundle your entrypoint file before feeding it through the framework's build process. E.g.:

1. Create a pre-build entrypoint file, jon-doe/example/_example.js
2. Install packages into your component directory
3. Browserify your pre-build entrypoint, with the output file being your actual entrypoint file, jon-doe/example/example.js
4. Let the framework build tool take over from there

That's annoying though, so...

The eventual solution(s)?

1.) We could include Browserify as part of our build process. Basically, check if the project directory has a package.json, then check for node_modules, npm i if necessary, and then browserify the necessary files before (or after) the main steps of our build. This is similar to what the Famous CLI deploy task does.

2.) More flexibly, we could allow the user to specify their own build hooks. I.e., a user could put this in their package.json:

"scripts": {
    "build-famous": "foobar"
}

Our build process would check for a package.json, and if the "build-famous" script is present in the "scripts" object, then we would run that prior to our build process. This seems like perhaps the most flexible approach.

Open to other suggestions here.

[andrewreedy]

👍 this sounds great!

[trusktr]

What about if no build hook is provided, default to #1, if a build hook is provided, apply #2 only?

For #1, what about using Webpack? Users could specify settings in webpack.config.js to override the default settings. The convention could be that a user's config gets _.merged onto famous-framework's internal webpack config, making it super flexible (f.e. I can add ES6 support to my project by adding the babel loader in my config file). Settings in Webpack can be project-wide, unlike with Browserify where transforms have package-scope (you get more power/control with Webpack, but you can mess up more horribly too, so Browserify is easier (until you need some random custom stuff that there's no way to configure in Browserify)).

[Tim-W]

@trusktr is Webpack an upcoming web standard? Have heard of it and sounds interesting but am not sure how well it is/will be supported.

Anyways, I'd vote for being able to use CommonJS and/or AMD modules.

[trusktr]

@Tim-W Webpack isn't a standard, it's just a tool that makes it possible to use competing standards (CommonJS, AMD, and ES6 modules) within a single app. It's just a build tool that lets you compile bundles out of entry points written using those module formats. Browserify is an alternative to Webpack, among others, that does the same thing basically.

[johnjelinek]

I'd like to hook jspm+gulp into this.