esperanto - npm Package Compare versions

Comparing version 0.3.8 to 0.3.9

lib/transform.js

		@@ -25,3 +25,3 @@ var acorn = require('acorn');

		replaced = '';
		replaced = source.slice( 0, body[0] ? body[0].start : 0 );

		@@ -28,0 +28,0 @@ len = body.length;

package.json

		{
		"name": "esperanto",
		"description": "An easier way to convert ES6 modules to AMD and CommonJS",
		"version": "0.3.8",
		"version": "0.3.9",
		"author": "Rich Harris",
		@@ -6,0 +6,0 @@ "dependencies": {

README.md

		@@ -10,2 +10,4 @@ # esperanto

		Try it online here: [rich-harris.co.uk/esperanto](http://www.rich-harris.co.uk/esperanto/)

		## Installation
		@@ -31,58 +33,5 @@

		Esperanto exposes two methods - `esperanto.toAmd()` and `esperanto.toCjs()`. Both methods take a `source` argument, which is the source code of an ES6 module, and an optional second argument, `options`.
		See the [wiki](https://github.com/Rich-Harris/esperanto/wiki) for other options.

		The `options` argument can have a `defaultOnly` property, which defaults to `false`. See the next section for an explanation.

		If you're using `esperanto.toAmd()`, you have two additional options:

		* `indent` (string) specifies how to indent the contents of the module. By default, esperanto will guess the correct indentation from the code, and default to a single tab character if it's not sure.
		* `addUseStrict` (boolean) determines whether the 'use strict' pragma should be added to the top of the module. Defaults to `true`.


		## When to use `defaultOnly`

		ES6 modules support both default and named imports and exports:

		```js
		// default
		import foo from 'foo';
		var bar = foo.toUpperCase();
		export default bar;

		// named
		import { foo, bar } from 'baz';
		var bar = foo.toUpperCase();
		export { qux };
		```

		See [jsmodules.io](http://jsmodules.io/) for an explanation of the difference.

		This is a good design, but [it poses problems](https://gist.github.com/domenic/4748675) for developers who want to use ES6 modules with existing codebases. An AMD representation of the first example above might look like this:

		```js
		define(['foo','exports'], function (__import_1,exports) {
		var foo = __import_1.default;
		var bar = foo.toUpperCase();
		exports.default = bar;
		});
		```

		As long as `foo` is also a transpiled ES6 module with a `default` property (or an AMD module that had a `default` property added by design), that's fine - as far as this module is concerned. But if `foo` is an external library, that almost certainly won't be the case.

		On the other side of the fence, if someone were to require this ES6 module from within an AMD module, they'd have the same problem in reverse.

		Esperanto's `defaultOnly` option solves this problem. As long as you're not using named imports or exports, it will cause modules to behave as you (as a seasoned user of AMD or CommonJS modules) would naturally expect:

		```js
		define(['foo'],function (foo) {

		'use strict';

		var bar = foo.toUpperCase();
		return bar;

		});
		```


		## Why not use existing module transpilers?
		@@ -155,3 +104,3 @@

		Leaving aside that minor problem, what does the result look like?
		Leaving that aside, what does the result look like?

		@@ -175,6 +124,6 @@ ```js

		Better, certainly, and you get source maps. Though as with [transpile](https://github.com/bitovi/transpile), you're stuck with named (as opposed to anonymous) AMD modules. Frankly, though, the external dependencies thing is a dealbreaker for me.
		Better, certainly, and you get source maps which is really cool. Though as with [transpile](https://github.com/bitovi/transpile), you're stuck with named (as opposed to anonymous) AMD modules. Frankly, though, the external dependencies thing is a dealbreaker for me.


		### esperanto
		### [esperanto](http://www.rich-harris.co.uk/esperanto/)

		@@ -192,6 +141,8 @@ Here's the code to generate AMD output:

		var foo = __imports_0.default;
		var bar = foo.toUpperCase();
		exports.default = bar;
		'use strict';

		var foo = __imports_0.default;
		var bar = foo.toUpperCase();
		exports.default = bar;

		});
		@@ -222,5 +173,4 @@ ```

		* A proper test suite (if you want to test esperanto, clone this module, `cd` into this folder, `npm install` dependencies, and run `node test.js`. The generated code will be written to the `output` folder)
		* Renaming imports (e.g. `import { unlink as rm } from 'fs'`)
		* Source maps?
		* Command line mode
		* Source maps... maybe
		* Allow named modules, if you're into that
		@@ -227,0 +177,0 @@

esperanto - npm Package Compare versions

Worsened metrics