Inferno: Importing inferno with rollup

[thepian]

Observed Behaviour

Inferno is difficult to import with rollup. The default import relies on require, and importing the src directly doesn't seem to work.

Expected Current Behaviour

Inferno should provide a way to import ES directly without crazy config. Standard module notation is clearly the future direction

Alternately document the use of alias to import ES, such as

import alias from "rollup-plugin-alias";
const plugins = [
    alias({
        "inferno": path.join(__dirname, "../node_modules/inferno/dist/index.es"),
        "inferno-component": path.join(__dirname, "../node_modules/inferno-component/dist/index.es"),
        "inferno-create-element": path.join(__dirname, "../node_modules/inferno-create-element/dist/index.es"),
    }),
]

Inferno Metadata

macOS

P.S. Is there a way to return array of elements from a render function?

[longlho]

let me try taking a look at this

[mienaikoe]

I use rollup with Inferno, and after some slogging, I got a working rollup config:

// rollup.config.js
import resolve from 'rollup-plugin-node-resolve';
import babel from 'rollup-plugin-babel';
import less from 'rollup-plugin-less';
import commonjs from 'rollup-plugin-commonjs';
import replace from 'rollup-plugin-replace';


export default {
  input: 'src/client.js',
  output: {
    file: 'dist/client.js',
    format: 'cjs'
  },
  plugins: [
    resolve(),
    less({
      output: "dist/client.css"
    }),
    babel({
      exclude: 'node_modules/**' // only transpile our source code
    }),
    commonjs(),
    replace({
      'process.env.NODE_ENV': JSON.stringify("production")
    }),
  ]
};

The trick is rollup-plugin-commonjs which is made specifically for importing from npm modules that use commonjs instead of es. It was buried in the documentation...

[OvermindDL1]

Just remember that things that need rollup-plugin-commonjs also mean they cannot be as well pruned or optimized as ES6 Module libraries, so you may quite often get more than what you expect in the output.

[thepian]

I think this shows that there is room for improvement. I may be wrong but ES6 seems a clear future direction, so finding a way to make it a first order citizen would be my recommendation. Loosing tree shaking for Inferno is a great shame.

I'd even accept an option to import via TypeScript which should provide an optimal compile

[longlho]

keep in mind tree-shaking offers no value for inferno since it's already tiny

[OvermindDL1]

@longlho Not just that but a lot of inlining and speed optimizations can be performed better on ES6 module code.

[longlho]

not really, the difference in ES6 module is the module loading mechanism, which, at the end of the day is just webpack/rollup concatenating things together and adjust scopes. Inlining is done via JIT in whichever interpreter you use, along w/ other speed optimizations (object stack/heap allocation, loop unrolling, scope hoisting...) during runtime depending on usage. Webpack/Rollup are bundler, not Ahead-Of-Time compiler like Angular CLI. They can handle dead code removal which reduces bundle size (thus parsing time) and some other hoisting tricks but that's about it. My point is the current module loading mechanism isn't optimal, but it already does NOT matter in your application.

We were exposing module field in package.json but that caused too many issues with people using ES6 module but not ES6 syntax and don't transpile dependencies. We can try introducing it again but that means you have to transpile inferno when you package things.

[OvermindDL1]

not really, the difference in ES6 module is the module loading mechanism, which, at the end of the day is just webpack/rollup concatenating things together and adjust scopes.

Some bundlers can inline specific functions from modules instead of entire modules, like rollup can with ES6 modules, which reduces filesize quite nicely. Although it 'tends' to not matter if something like google's closure compiler is run over the code (depending on what is exposed and what is not, and for commonjs modules they tend to get globally exposed via their return so they do not always get pruned properly).

We can try introducing it again but that means you have to transpile inferno when you package things.

Generally what I do with all my dependencies anyway. ^.^

[thepian]

I understand your point about the tiny size. If I was to digress I'd say; However I see the main appeal for Inferno being regular websites rather than SPA. For SPA a loading time in seconds can often be acceptable so it's not worth worrying much about bundle size under 1Mb. I seek to make Reactive Websites with a great UX, so I can't accept visual load time due to payload size, hence my bundle budget is around 200Kb. At that level each Kb does matter.

Yet as a digression this has little to do with the Issue at hand. I think it would be worth considering distributing a single index.es.js with import statements for external modules.

[OvermindDL1]

For SPA a loading time in seconds can often be acceptable so it's not worth worrying much about bundle size under 1Mb.

For note, that'll make it fail the chrome audit as over cell networks downloading something over a meg in size can take 15+ seconds.

Yet as a digression this has little to do with the Issue at hand. I think it would be worth considering distributing a single index.es.js with import statements for external modules.

Whoo!

[thepian]

Well any solution will be appreciated. I haven't managed to make a reliable import of inferno so far.

[Havunen]

There was bug that ES6 code was built using development settings. I will hotfix this for 3.10, then you can use alias as shown in the first post of this thread.

• Until better way to import inferno with rollup is found.

[scripter-co]

@Havunen I know you're the one that removed it, but why was the module field actually removed? Putting it back into the packages would resolve the rollup issue as it'd point to the ES6 file without having to do any funky stuff with the namedExports param or alias plugin. I'm not even sure how used the inferno:main field is.

[longlho]

we can reintroduce module field w/ ES import + ES6, just that people would have to transpile inferno when they package too, which at the time was a fairly confusing thing for a bunch of people

[scripter-co]

@longlho are you happy for me to open a PR to address this? If so, I assume we want an additional key formodule and leave inferno:main intact.

[longlho]

ping @Havunen: we're ready to give this another try?

[Havunen]

Yes lets add module entry point again for V4. @longlho lets close this issue.

[scripter-co]

@Havunen I can get a PR in for this, which branch should it go into?

[Havunen]

@scripter-co That would be great! dev branch please :+1:

[scripter-co]

@Havunen https://github.com/infernojs/inferno/pull/1249