feature/remove cjs assert

[a-tarasyuk]

No description provided.

[btraut]

Looks like a reasonable change, but on code that really should be further updated -- asserts should never exist in production code. I recommend eventually following up by adding babel or some other build step to create both a dev and prod build of ReSub, and using that flag to conditionally strip out all asserts.

[deregtd]

My philosophy here is that anyone USING these sorts of libraries should simply implement babel if they want truly production-ready code, and use that to remove assets, minify, etc. Out of the box, for simpler projects, leave the asserts so people know when they've messed up. Anyone doing any real production-level code should be implementing a full release pipeline anyway.

[a-tarasyuk]

@btraut thanks for your feedback., This PR is the first step to move away from cjs-assert, so I think changes related to the build process should be done in a new PR if these changes are necessary.

@deregtd Some of the optimizations can be tricky, like with lodash and could add an additional headache for users., As you know, I did investigations which shows that using entire lodash import in a library is bad, and the bundle will include entire lodash even with babel plugins which users apply to production code. Anyway, I think, would be helpful to add comments about some useful plugins which users have to apply in order to avoid issues related to bundle size.

[deregtd]

They can certainly be tricky, and pointing out how people should fix their build systems is certainly helpful. But I don't want to, say, remove all assert calls from our dist .js files on the public NPM repo for ReSub just to save public users a tiny bit of space. Lodash pre-optimizations don't cause our users any hassles, and it just saves them space with no real downside, but pre-optimizing-out assert calls hurts people.

[btraut]

Problem with leaving optimizations such as removing asserts from external libraries to the exercise of the user is that it requires a lot of internal knowledge of those libraries and different treatments for each. Rather than naming it assert, you could've used a different name or used console logging instead of throwing errors. By breaking ReSub out into its own module rather than inlining it in your project, you're taking on the burden of its build pipe, and that includes optimizations.

I'm inclined to follow React's lead with this stuff: asserts and error logging should only ever be present at dev time. Errors in prod will be more cryptic, but they're going to be minified anyway.

Anyway, I agree that this is unrelated to this PR in particular.

[deregtd]

How do you release a library with dev and production versions? Is there an NPM standard for that? I'm okay differentiating and removing ourselves if there's some way to release multiple versions in a single package. I'm under the impression you can only release a single library with NPM, so for that single library you have to go to the lowest common denominator (including asserts.)

[a-tarasyuk]

If we are talking about React - it has several versions. By default, React will be in development mode. On NPM it completely relies on NODE_ENV, users have to worry about setting the environment in bundlers which they use, and nothing more.

index.js 

if (process.env.NODE_ENV === 'production') {
  module.exports = require('./cjs/react.production.min.js');
} else {
  module.exports = require('./cjs/react.development.js');
}

Also, there is opportunity to use UMD.

In the production version, it replaces errors with one error.

'Minified React error #' +
      code +
      '; visit %s ' +
      'for the full message or use the non-minified dev environment ' +
      'for full errors and additional helpful warnings. ',

For instance, Redux provides development/production versions only for UMD. Redux has ES2015 and CJS versions which have only one version which exists on NPM.

If it is necessary we can return to the discussion which I closed some time ago on SimpleRestClients, where I migrated library on Rollup + Babel to automate the build process.