bundlers: process.env.NODE_ENV in rollup breaks build about hybrids HOT 15 CLOSED

The problem with process.env.NODE_ENV is solved in last v2.0.0 release. It is a simple trick to check if that object exists. It also doesn't break minification feature where the code is replaced with a string value.

try { process.env.NODE_ENV } catch(e) { var process = { env: { NODE_ENV: 'production' } }; }

The line is removed for production usage with bundlers. Those which does not support that feature, it still works, by fallback to 'production' value (in the catch block).

For now, the dist/hybrids.js built version is already minified with "production" value. Other targets - lib/index.js and esm/index.js are not minified and relay on process.env.NODE_ENV value with fallback, if it is not set.

from hybrids.

Yes i will do a new issue for discussing

from hybrids.

it is not a bug. It is not yet well documented, but hybrids like other libraries uses process.env.NODE_ENV pattern to distinguish development and production mode. In the latter, some of the code is cut out, and some checks are not called.
You can find issues in the rollup repository, looking for "rollup process is not defined". One of the issues that might help you is here: rollup/rollup#487

Webpack and Parcel supports process.env.NOD_ENV out of the box. I recommend you to try parcel-bundler. In my opinion, it works the best with hybrids. HMR works out of the box, no other problems and no configuration required - install it and call something like this parcel src/index.html.

Feel free to re-open, if you have any other questions in this subject.

from hybrids.

Ok thanks, will test parcel.
The idea behind this issue is to benchmark Hybrids with other librairies.

https://github.com/vogloblinsky/web-components-benchmark

I will add Hybrids inside this afternoon. Feel free to have a look ;)

from hybrids.

Great idea. One hint - rendering using render factory is async, and if it takes to long it can be either postponed to next frame. If your benchmark relays on synchronous rendering I recommend reading the conversation from #18 (especially this comment). One of the solutions is to create own version of render, which uses html - benchmark will still be accurate - as a time of changes is most important, not when they occur.

I have plans to create benchmarks for the library in the near future, but now I am mainly focused on creating docs and spreading the news about the library to the community.

from hybrids.

The benchmark use puppeteer + lighthouse to extract metrics from devtools performance tab. It starts before running the bench, and stop after, so i think it will not be a problem for hybrids.

from hybrids.

Cool. I read on your site, that you compile to ES6/ES2015. To do so with hybrids, you should import from src:

import { ... } from 'hybrids/src';

All targets from package.json are transpiled to es5, the difference is only with import/exports from commonjs to ES modules.

from hybrids.

And write me, when you finish benchmarks :)

from hybrids.

Is there a reason why you don't use rollup or parcel for packaging instead of Webpack? That way a ES6 variant could be offered next to a transpiled one.

from hybrids.

Webpack is only used to created built version. It is more a fallback for users, which don't use bundlers themselves.

Why not a Rollup? I am just more familiar with Webpack, and it was easier for me to setup karma with it. Npm package contains ES2015 source code in src path.

import { html, render } from 'hybrids/src';

As not all bundlers supports transpiling node modules out of the box yet, package.json points only transpiled (by the babel directly) version with imports/exports.

from hybrids.

I was just wondering. Of course "hybrids/src" is an option, if you use bundlers.
I was more thinking of pointing my browser to something like "https://unpkg.com/[email protected]/dist/hybrids.jsm" or so and use full ES6 module syntax.

Redux does this for example, they offer a UMD (https://unpkg.com/[email protected]/dist/) and ES variant: https://unpkg.com/[email protected]/es/

You would basically copy their rollup config file (https://github.com/reduxjs/redux/blob/master/rollup.config.js)
and call npx rollup to generate the dist and keep webpack for testing.

from hybrids.

The npm package has all versions now, there is lib, esm and src. It would be possible to use esm directly in the browser as an ES module, but... You can't. The library uses process.env.NODE_ENV pattern to switch between development and production modes. Only because of that, it throws an error when loaded.

I am not sure how to solve that problem. The hmr module is not required when used on production, as well as some checks.

For now, only built version (compiled by the weboack) is in production mode by default and can be used directly in the browser.

from hybrids.

Redux uses the same pattern and the linked rollup config does a string replacement ('process.env.NODE_ENV': JSON.stringify('production')). Webpack could do the same, probably.

from hybrids.

Ok, I will look at the redux configuration. What I understand from what you wrote, is that all versions built in npm package are in production mode, only that is pointed by the package.json have process.env.NODE_ENV.

from hybrids.

all versions built in npm package

"scripts": {
    "format": "prettier --write \"{src,test}/**/*.{js,ts}\" index.d.ts \"**/*.md\"",
    "test": "jest",
    "build": "rollup -c",
  },

All versions build with npm run build seem to be production mode, yes.

from hybrids.