Publish npm module without minification

[jhamlet]

The main property field of the falcor/package.json should point to the dist/falcor.js file instead of the dist/falcor.min.js field.

[trxcllnt]

@jhamlet In this case, I think it'd like to do something similar to the React team, e.g. if process.env.NODE_ENV is "production", require the minified build, and if it's anything else, require the non-minified build. I've already inserted a few checks on edge cases that will warn about potential foot-guns during dev mode, and would like to add more, but an external build process might not know to eliminate that code in production builds.

[jhamlet]

Sounds good to me.

[jameslaneconkling]

How would a downstream project require the unminified version? e.g. this

if (process.env.NODE_ENV === 'production') {
  import falcor from '@graphistry/falcor';
} else {
  import falcor from '../node_modules/path/to/falcorjs';
}

is invalid javascript.

Would it be simpler to just export the unminified code, under the assumption that any downstream project that wants a minified build will already have built that into their build pipeline?

[trxcllnt]

@jameslaneconkling we do that at @graphistry in a project's webpack config:

{
    resolve: {
        alias: {
            '@graphistry/falcor': path.resolve(isDevBuild ?
                './node_modules/@graphistry/falcor/dist/falcor.all.js' :
                './node_modules/@graphistry/falcor/dist/falcor.all.min.js'
            )
        }
    }
}

To reduce some of the weird internal keys for dev and prod, the falcor build relies on Webpack's DefinePlugin to inline our internal keys in place of identifiers, which is why the build is necessary. We've found this approach is faster at runtime than using constant identifiers for internal-key comparisons and lookups.

[jameslaneconkling]

Didn't know you could do that w/ webpack. I'll update my build.

Thanks for the pointer.