Unable to provide binary executable globally

Question

Unable to provide binary executable globally

DaGhostman opened this issue 8 years ago · 11 comments

According to this issue on the ts-node repo ts-node does not transpile files inside node_modules, so this project making the executable a TS file is not possible (sigh), and this might be related to #1's last comment about php-inspections not being available at all (the bin in package.json is empty, but on investigaing it turns out to be a huge show stopper, since this is a CLI tool...)

Answer 1 · 2016-12-23T20:03:55.000Z

You should also commit your dist directory

Answer 2 · 2016-12-23T20:35:45.000Z

it's working for me :

devbox@devbox:~/Documents/glayzzle/ts-php-inspections$ sudo npm install https://github.com/glayzzle/ts-php-inspections#develop -g
npm WARN lifecycle php-inspections@0.0.1~preinstall: cannot run in wd %s %s (wd=%s) php-inspections@0.0.1 typings install && tsc /usr/local/lib/node_modules/.staging/php-inspections-3717e9cf
/usr/local/bin/php-inspections -> /usr/local/lib/node_modules/php-inspections/dist/bin/php-inspections.js
/usr/local/lib
└─┬ php-inspections@0.0.1  (git+https://github.com/glayzzle/ts-php-inspections.git#84c3d03544901667111e7f539e72eb2e843a2850)
  └── php-parser@0.1.4 

devbox@devbox:~/Documents/glayzzle/ts-php-inspections$ php-inspections 
Not enough arguments
devbox@devbox:~/Documents/glayzzle/ts-php-inspections$ php-inspections --help


+----------=============[ PHP Inspections]=============----------+
|  Version: Dev                                                  |
+----------------------------------------------------------------+
|  --pretty: Outputs results as readable text                    |
|  --as-json: Outputs results as JSON (useful for 3rd party apps)|
+----------------------------------------------------------------+


Error: Last argument must be the file/directory to inspect


devbox@devbox:~/Documents/glayzzle/ts-php-inspections$

Answer 3 · 2016-12-23T20:36:28.000Z

Well for now at least babel is out of scope I am just starting to get a grip on the behaviour of node in general (was staying away from JS for quite some time).

Now that is resolved and the script SHOULD transpile once installed, binary should be available, ts-node is an optional dependency for development (if it floats your boat) so this issue should be done

@ichiriac Would you be able to try and see if the latest changes fix the issue, since I am trying to stay as much away from mixing TS & JS files in the project (makes it look cleaner IMO)

Answer 4 · 2016-12-24T12:23:06.000Z

@DaGhostman

It's working :

devbox@devbox:~/Documents/glayzzle/php-parser$ sudo npm install -g https://github.com/DaGhostman/ts-php-inspections.git#develop
/usr/local/bin/php-inspections -> /usr/local/lib/node_modules/php-inspections/bin/bin.js

> php-inspections@0.0.1 postinstall /usr/local/lib/node_modules/php-inspections
> tsc

/usr/local/lib
└─┬ php-inspections@0.0.1  (git+https://github.com/DaGhostman/ts-php-inspections.git#9e96b717602503c7c0a950cfa5cb1150f3460e58)
  ├── @types/node@6.0.53 
  └── php-parser@0.1.4

But it seems that you need a dependency with @types/node, don't understand why, and also requires tsc to build files on the host (usually not installed, so by default will trigger errors from npm installs).

Also there is no main entry file for importing the API programmatically, exploiting results without the cli.

As typescript is not directly compatible with nodejs it's not so strange to share the dist folder and update it before each release, so your API will have a native support for any nodejs distro.

Answer 5 · 2016-12-24T12:37:31.000Z

The dependency on @types is to aid typescript to find the types for nodejs without requiring users to have typings globally installed.

On the decision about typescript is mainly because I kinda prefer TS over JS as it adds a decent amount of benefits compared to JS (even with the new additions to the project), this reminds me that I have to add some installation steps (to avoid confusion).

And last but not least, as for the ability to import the classes directly in node projects, I will look in to it and take an approach similar to the one I am taking with the bin/bin.js and feel free to open a separate issue so I can add it to the milestone for the first release

Answer 6 · 2016-12-24T12:54:48.000Z

Ok thanks @DaGhostman, I understand better why @types is in distributed dependencies instead in dev dependencies.

BTW, I don't say you should not use typescript, is up to you to use what ever you want, the choice is yours, and better I'm agree with your choice of typescript, I found the principle behind TypeScript great.

That said, like coffee scripts, you are using a tool that is not distributed and typescript needs a js conversion to run under nodejs. The postinstall trick works, but adds 2 new dependencies in your project in order to be run under (tsc & types)

You see, I'm just saying that if you want that your API can be simply installed on any nodejs/npm plateform and used without any typescript dependency you maybe should consider comiting the dist folder.

Also, if a project that is under classic nodejs would require as a npm dependency your project, would need in order to be deployed the same requirements of tsc - so you will limit your library to be used only into typescript ecosystem projects.

Answer 7 · 2016-12-24T13:07:39.000Z

Hmm, seems like a very valid point and while TS is good, there are people who probably prefer to write in pure JS instead and adding additional (unneeded) dependencies is bad and annoying I will consider it, I have a few thing in mind and will ping you in a separate issue after I research them a bit and they are viable enough :)

Thank you very much for the input I appreciate it greatly 🍻

Answer 8 · 2016-12-24T17:31:09.000Z

Well the dist folder will not be included at all :), now let me provide the sources for the decision:

This SO question justifying why generated JS should NOT be comitted to VCS - I couldn't agree more that the generated code is a build artifact + when compiling the package it will ensure compatibility between the package and the environment. Also the generated code will clutter the repo and there will be a lot of code that does not belong there as it goes agains the idea of VCS.
This article describing a possible approach - How to structure everything, what does when, even if it is a bit outdated, it gives a good idea on how to structure everything and what is happening when
Another article describing the same process
This SO answer on how to provide TS project to npm: Basically the approach is to handle everything in prepublish so when publishing to NPM the package there will not have any any of the source files, but will have the type definitions (used by compiler to know what to do when transpiling the TS code, just like what is in "@types" now)

So with that being said, this is still a dev project and the workaround at the moment will be fixed to a post-install hook or something for the time being, when the package is published it will not matter to the users. So this issue will remain open until those things are implemented.

Answer 9 · 2016-12-27T14:59:32.000Z

At present this is no longer valid, since this will be even better solved when the package is published to NPM, so that being said I will close the issue and we'll see how it goes

Answer 10 · 2016-12-27T15:02:53.000Z

@ichiriac Also latest changes on develop branch provide access to the project classes from within nodejs (also implemented using the same approach as the one for binary - depends on tsc)

If there are any issues, please feel free to open a separate issue

Answer 11 · 2016-12-27T15:50:52.000Z

@DaGhostman glad to see you found a clean way to support nodejs 👍

I plan to use your API into https://github.com/glayzzle/php-reflection in order to test it's integration with nodejs.