browserize

browserize

Converts simple node.js modules into ES6 modules.

• What it is
  • What it does
  • What it does not
  • When to use
  • When not to use
  • "But browserize does almost what I need"
• How to use it
  • CLI
  • node API
  • Requirements

---

What it is

• What it does
• What it does not
• When to use
• When not to use
• "But browserize does almost what I need"

What it does

browserize turns this:

module.exports = function main() {}

const extra = 'EXTRA',
module.exports = {
	extra,
}

into this:

export default function main() {}

const extra = 'EXTRA',
export {
	extra,
}

Recognizes references to main

browserize turns this:

module.exports = function main() { return common }

const main = require('./main')
module.exports = {
	extra: main,
}

into this:

const common = 'CONSTANT'
export default function main() { return common }

export {
	extra: main,
}

This relies

Merges constants and Variables

browserize turns this:

const common = 'CONSTANT'
module.exports = function main() { return common }

const common = 'CONSTANT'
module.exports = {
	extra: common,
}

into this:

const common = 'CONSTANT'
export default function main() { return common }

export {
	extra: common,
}

and this:

let common = 'VARIABLE'
module.exports = function main() { return common }

let common = 'VARIABLE'
module.exports = {
	extra: common,
}

into this:

let common = 'VARIABLE'
export default function main() { return common }

common = 'VARIABLE'
export {
	extra: common,
}

NOTE: Since browserize cannot know if common gets changed in main.js, it leaves the assignment in place. If the variable is not assigned in the second file, the declaration is removed.

What it does not

browserize does not:

• check if the result will run in a browser
• transform requires into imports
• bundle dependencies àla Webpack/Rollup
• transpile anything other than JavaScript, like CoffeeScript (it might work by coincidence, but there's no support for that)

When to use

browserize is made for small packages without dependencies that should run both in node.js and in the browser.

When not to use

If your package has any dependency, it's probably complex enough to warrant babel, webpack, or some such. Use that instead.

If you need to transpile anything, like CoffeScript or TypeScript, your tooling for that should cover you.

"But browserize does almost what I need"

Open an issue, and let's talk about it 😉

How to use it

• node API
• CLI
• Requirements

NOTE: If you want to interpolate imports, you need to use the node API. This feature is currently not available for browserize/fs and consequently for the CLI.

node API

You can import either browserize or browserize/fs, depending on how you will use it.

browserize takes an options object with three optional entries:

• main: a string containing the main/default export
• named: a string containing the named exports
• imports: a key/value store that maps import paths to replacement values

browserize/fs takes an options object with three optional entries:

• main: the file where the main/default export is found, defaults to index.js
• named: where to find the named exports, defaults to null
• output: where to write the ESM file, defaults to the main or named filename with the extension .mjs

And that is it.

Examples

The simplest form

const browserizeFS = require('browserize/fs')
browserizeFS()

This reads index.js and writes the equivalent index.mjs, and that's it.

Handling in-memory files

const fs = require('fs-extra')
const browserize = require('browserize')
const main = fs.readFileSync('main.js').toString()

browserize({ main })

Turns the content of main.js into its ESM version. This is mainly useful if you want to integrate with a build setup using in-memory files, like gulp.

The most complex case browserize/fs covers

const browserize = require('browserize')

browserize({
	default: 'class-name.jsx',
	named: 'helper-functions.js',
	output: 'dist/browser-magic.js',
})

This includes named exports and sets custom paths for everything.

Replacing imports

const fs = require('fs-extra')
const browserize = require('browserize')
const main = fs.readFileSync('main.js').toString()

browserize({
	main,
	imports: {
		'./constant': 'CONSTANT',
	}
})

Using this feature, you can extract constants for common use in node files and still have an ESM file without dependencies.

IMPORTANT: The keys are matched verbatim, so imports:{'./x':'X'} will do nothing for require('./x.js').

NOTE: This only works for simple values, like strings and arrays, not functions or classes.

CLI

npx browserize [--no-default|-x] [[--default|-d] index.js] [[--named|-n] helpers.js] [[--output|-o] index.mjs]

The CLI passes the given arguments through to the underlying node API, and works through browserize/fs.

Examples

The simplest form

npx browserize

This reads index.js and writes the equivalent index.mjs, and that's it.

Adding named exports

npm browserize -n helper-functions

This reads index.js and helper-functions.js, then transforms concatenates them, and finally writes the result to index.mjs.

The most complex case browserize covers

npx browserize class-name.jsx helper-functions.js dist/browser-magic.js

This includes named exports and sets custom paths for everything.

Requirements

browserize is a simple tool and has a few simple requirements:

Each source file must contain exactly one assignment to module.exports

Good

module.exports = class DefaultExport {}

module.exports = {
	key1: helper1,
	key2: helper2,
}

Bad

exports.key1 = helper1
exports.key2 = helper2

While valid, browserize does not know how to transform this.

module.exports = export1
module.exports = export2

This is not useful anyway.

window.myStuff = class DefaultExport {}

This is not a module.

The default export must be declared without a newline between the assignment operator and the exported item

Good

module.exports = class DefaultExport {}

module.exports = class DefaultExport {
}

Bad

module.exports =
class DefaultExport {}

While this is valid in node.js, it will lead to an invalid ESM file.

The named exports must be declared as an object literal

Good

module.exports = { helper1, helper2 }

module.exports = {
	helper1,
	helper2,
}

Bad

module.exports.helper1 = helper1
module.exports.helper2 = helper2

While this is valid in node.js, browserize does not understand it.

This is too complex, and has no real benefit over the object literal.

The named exports must use shorthand syntax

Good

module.exports = {
	helper1,
	helper2,
}

Bad

module.exports = {
	helper1: helper1,
	helper2: helper2,
}

module.exports = {
	key1: helper1,
	key2: helper2,
}

While this is valid in node.js, it will lead to an invalid ESM file.