Support for ES6 about deamdify HOT 11 CLOSED

You'd use babelify first, deamdify doesn't need to know anything about ES6 in order to function.

from deamdify.

Just followed your link, are you not transpiling? If so, that's going to cause problems in more than just deamdify. We could definitely upgrade esprima, so long as tests still pass and it fixes your problem.

If tests break, or your use case isn't fixed I wouldn't bother upgrading it.

from deamdify.

That's right, no transpiling.. My app is a backend app (that runs in a
browser). It does a lot of math and 3D visualisation, in order to generate
drawings/specifications of curved playground houses. It's the future of
playground things :D
Because of all the computation, I'm fairly stretched on the
performance-budget when I'm working on the app day to day. That's why I
prefer to skip transpilation (and also for the sake of simplicity in
debugging. I'm very new to node and haven't looked at source maps yet).

I'll be glad if you would try to upgrade esprima. Wouldn't you need to do
so anyways, once ES6 becomes sufficiently widespread?
Den 12/01/2016 23.38 skrev "Tim Branyen" [email protected]:

Just followed your link, are you not transpiling? If so, that's going to
cause problems in more than just deamdify. We could definitely upgrade
esprima, so long as tests still pass and it fixes your problem.

If tests break, or your use case isn't fixed I wouldn't bother upgrading
it.

—
Reply to this email directly or view it on GitHub
#36 (comment)
.

from deamdify.

The published version of deamdify on npm is still using Esprima 1.x, hence why it wont' understand ES6 syntax.

Meanwhile, this master branch's package.json seems to indicate Esprima 2.x. So it's probably a matter of publishing a new version of deamdify?

from deamdify.

Hi Tim

Not to rush you, but do you have an estimate on the time frame needed for
trying to make deAMDify work with esprima 2.x?
I need to make a decision on whether to start converting my modules
manually, or wait it out.

/Jon

On 13 January 2016 at 01:30, Ariya Hidayat [email protected] wrote:

The published version of deamdify on npm is still using Esprima 1.x, hence
why it wont' understand ES6 syntax.

Meanwhile, this master branch's package.json seems to indicate Esprima
2.x. So it's probably a matter of publishing a new version of deamdify?

—
Reply to this email directly or view it on GitHub
#36 (comment)
.

from deamdify.

Can you test by installing the current master in your project to see if it will help first?

npm install jaredhanson/deamdify

Or put that in your package.json. That should pull from the latest master.

from deamdify.

It worked, in the sense that I now get a different error message:

jon@Lemur:~/frontend$ browserify -t deamdify js/test_browserify.js -o

js/test_bundle.js
Error: Cannot find module 'utils/approx' from
'/home/jon/frontend/js/cons/designs'
at
/usr/lib/node_modules/browserify/node_modules/resolve/lib/async.js:46:17
at process
(/usr/lib/node_modules/browserify/node_modules/resolve/lib/async.js:173:43)
at ondir
(/usr/lib/node_modules/browserify/node_modules/resolve/lib/async.js:188:17)
at load
(/usr/lib/node_modules/browserify/node_modules/resolve/lib/async.js:69:43)
at onex
(/usr/lib/node_modules/browserify/node_modules/resolve/lib/async.js:92:31)
at
/usr/lib/node_modules/browserify/node_modules/resolve/lib/async.js:22:47
at FSReqWrap.oncomplete (fs.js:82:15)

This massage indicates that the module references present in my
home/jon/frontend/js/cons/designs/SuperQuadric file are interpreted as
relative references, rather than as originating from my standard path
reference from my time with require.js (which is /home/jon/frontend/js).
The correct path to utils/approx is: /home/jon/frontend/js/utils/approx

Is there a way to tell this detail to deAMDify, or do I need to update the
paths manually?

Den 13/01/2016 20.07 skrev "Tim Branyen" [email protected]:

Can you test by installing the current master in your project to see if it
will help first?

npm install jaredhanson/deamdify

Or put that in your package.json. That should pull from the latest master.

—
Reply to this email directly or view it on GitHub
#36 (comment)
.

from deamdify.

@loldrup depending on your current project scale and your time requirements it might be better for you to prefix your require calls to use relative file pointers like ../ and ./ instead of relying on the global paths. This would most likely fix your problem and lend to closer parity with CommonJS. You could mess around with paths, but since you're compiling directly to CJS you may want to align your module requires closer to that.

from deamdify.

Okay cool, I'll push a new version!

from deamdify.

Updated the module in NPM to 0.2.0. Please give this a try and close the issue once you're good to go.

from deamdify.

It works! :D

from deamdify.