global installation is not working because of hardcoded path of prototypes

Hi,
I've installed (apparently successfully, few warnings about unmet dependencies) extendscriptr, but when I try to run a simple:

$ extendscriptr --script ./test.js --output ./test_enc.js

I get this error:

Running extendscriptr with following options:
--script: ./test.js
--output: ./test_enc.js
--target: undefined (optional)
fs.js:584
  return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                 ^

Error: ENOENT: no such file or directory, open './node_modules/extendscript.prototypes/lib/extendscript.prototypes.js'
    at Error (native)
    at Object.fs.openSync (fs.js:584:18)
    at Object.fs.readFileSync (fs.js:431:33)
    at Object.<anonymous> (/usr/local/lib/node_modules/extendscriptr/index.js:27:29)
    at Module._compile (module.js:397:26)
    at Object.Module._extensions..js (module.js:404:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Function.Module.runMain (module.js:429:10)
    at startup (node.js:139:18)

Any idea about the reason why this occurs?
Thank you!

Davide

@undavide

Hi @undavide thanks for the report. Looks like the prototypes module is missing. The packag.json says 0.0.8 but the module is at 0.0.9 I'll try this out ASAP.

@vogelino

CC @vogelino

@undavide

hi @undavide,

I took a look at that issue and tested it with node v4.2.4 (npm version 2.14.12) and can confirm that bug.

So what Node version are you using?
What is your npm version?
What OS are you on?

apparently successfully, few warnings about unmet dependencies

What where these warnings?

I traced it down I think. In index.js line 27 we make a direct reference to the prototypes module. The folder structure of node_modules got flattend after version 4.

A quick fix would be using a higher Node.js version (I recommend nvm for that. You can have several Node.js versions for different projects) or you go into /node_modules/.bin/extendscriptr and change the line 27 to point at the prototypes directory.

Also I suggest installing the tool as a local devDependency. Yes we need to change that in the README.md

We will let you know when we've fixed that issue.

update README reference #22

My bad for not having provided the node version I'm using, which is 5.4.1 (npm 2.14.7), OSX latest.

No problemo. I tested it with node 6.3.0 (works), node 5.1.0 (works) and node 4.2.4 (does not work). Strange that it does not work with v5 for you. Can you take a look if the folder structure in the node_modules is flat or nested? I took a look around. It looks like npm v3 introduced the flat folder structure. So to make this work we need currently npm v3

Hi there,

Indeed there is a node version Problem. I matter of time, I did not
comcentrate on making it cross-node-versions compatible. We should at least
define the engines in the package.json to document that. I also agree that
the readme should be updated. I'll make those changes when I come back from
Brussels next week. Nevertheless, if you feel comfortable with doing it
yourself, feel free to do it or to make a pull request.

Bests.

Le lundi 18 juillet 2016, Fabian Morón Zirfas <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> a écrit :

No problemo. I tested it with node 6.3.0 (works), node 5.1.0 (works) and
node 4.2.4 (does not work). Strange that it does not work with v5 for you.
Can you take a look if the folder structure in the node_modules is flat or
nested? I took a look around. It looks like npm v3 introduced the flat
folder structure. So to make this work we need currently npm v3

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#22 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACoarL8GySif_wjB5wmdEl1sAWahOSv1ks5qW0qSgaJpZM4JOU7-
.

Sent from my phone. Please excuse my brevity.

@fabiantheblind

Hello, here is the error that I keep getting after having installed node-latest (via nvm), and using global extendscriptr:

$ which extendscriptr
/Users/davidebarranca/.nvm/versions/node/v6.3.0/bin/extendscriptr
$ extendscriptr --script ./in.js --output ./out.js
Running extendscriptr with following options:
--script: ./in.js
--output: ./out.js
--target: undefined (optional)
fs.js:640
  return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                 ^

Error: ENOENT: no such file or directory, open './node_modules/extendscript.prototypes/lib/extendscript.prototypes.js'
    at Error (native)
    at Object.fs.openSync (fs.js:640:18)
    at Object.fs.readFileSync (fs.js:508:33)
    at Object.<anonymous> (/Users/davidebarranca/.nvm/versions/node/v6.3.0/lib/node_modules/extendscriptr/index.js:27:29)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Module.runMain (module.js:575:10)
$ node --version
v6.3.0
$ npm --version
3.10.3

The local version works as expected, though.

@fabiantheblind you asked me whether the node_modules folders are flattened or nested, this is a screenshot:

(hopefully I'm looking in the right folder...!)
Thank you!

Hm the folder looks like the structure is not flat. Did you uninstall extendscriptr before installing it with your nvm node version?

I think you are still using the npm<3 version. nvm installs modules in your ~/ directory.

But your which command points to the nvm folder. Even weirder

Can we close this issue? Or does it still stand?

I've recently cleaned all node and node related stuff (it can really mess things up to an unbearable level). Since there's no node uninstaller, I've followed few blogposts and manually bombed several folders. n, nvm included.
Then I've installed Node-latest, and extendscriptr (globally).
Per se, it installs correctly, with just one warning:

npm WARN deprecated babel@6.5.2: Babel's CLI commands have been moved from the babel package to the babel-cli package
/usr/local/bin/extendscriptr -> /usr/local/lib/node_modules/extendscriptr/index.js

But then, again...

$ extendscriptr --script ./John.js --output ./test_enc.js
Running extendscriptr with following options:
--script: ./John.js
--output: ./test_enc.js
--target: undefined (optional)
fs.js:640
  return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                 ^

Error: ENOENT: no such file or directory, open './node_modules/extendscript.prototypes/lib/extendscript.prototypes.js'
    at Error (native)
    at Object.fs.openSync (fs.js:640:18)
    at Object.fs.readFileSync (fs.js:508:33)
    at Object.<anonymous> (/usr/local/lib/node_modules/extendscriptr/index.js:27:29)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)
    at Module.runMain (module.js:590:10)
$ node --version
v6.6.0
$ npm --version
3.10.3

Okay. Thank you so this line is messing it up

https://github.com/ExtendScript/extendscriptr/blob/master/index.js#L27

... and it's also the reason why installing it locally works, but globally it doesn't, am I correct?

yes. Thats the case.

I think the problem is that we are referencing it by path. If we had it as a working module it would work fine. But then again extendscript would not have all the prototypes it needs to run the module. 😠 I guess global install is off the table for now.

Hi evereybody!

I haven't been really reactive this summer as I have been quite busy and in vacations. Sorry about that. In facts, as I first wrote the npm module I never thought about testing a global install. Thank you for reporting this issue. It was initially done as a course project and has been a quite experimental projects. There are still lots of polyfills missings to make it really usable and the global installation error doesn't help. I'm glad to see that there is interest in the project and will have a look at it as soon as I get more free time again. In the meantime, let me thank you for contributing or reporting issues. I will keep an eye on it but will probably not contribute too much myself in the near future. Thank you for understanding.

Cheers!

and in vacations. Sorry about that.

Yeah you should be sorry that you had a vacation. 😉

As far as I am concerned, missing polyfills would have higher priority over a globally available command. The project itself is very much interesting, no doubts!
Thanks
–Davide

@undavide

@undavide I started with @EugenTepin a new repo for that. We could use some input on the structure of a repo like this. ExtendScript/extendscript-es5-shim#2

To make this package globally available we should do the following:

copy the shim into a local directory of the package with each build process
use this version instead of a reference to the version in the node_modules

Navigation Menu

Repository navigation

global installation is not working because of hardcoded path of prototypes #22

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

global installation is not working because of hardcoded path of prototypes #22

Description

Activity

ff6347 commented on Jul 18, 2016

ff6347 commented on Jul 18, 2016

ff6347 commented on Jul 18, 2016

undavide commented on Jul 18, 2016

ff6347 commented on Jul 18, 2016

vogelino commented on Jul 18, 2016

undavide commented on Jul 19, 2016

ff6347 commented on Jul 19, 2016

ff6347 commented on Jul 19, 2016

ff6347 commented on Sep 29, 2016

undavide commented on Sep 29, 2016

ff6347 commented on Sep 29, 2016

undavide commented on Sep 29, 2016

ff6347 commented on Sep 29, 2016

ff6347 commented on Sep 29, 2016

vogelino commented on Sep 30, 2016

ff6347 commented on Sep 30, 2016

undavide commented on Sep 30, 2016

ff6347 commented on Sep 30, 2016

ff6347 commented on Oct 5, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions