It would be preferable to be able to install Haxe (optionally) using NPM. I see that there is a “haxe” package on NPM now, but it is out-of-date, and seems to not be maintained.
Requiring web developers to have Haxe installed separately creates unnecessary friction.
Can we outline what technical factors make this difficult, such as Neko, or possible issues in how Haxe expects to behave? I’m interested in helping in the effort, anyone else? @andyli?
I know you guys like npm, and I can see how it’s useful if it works. But there are lots of difficulties in getting the details right.
npm is good for JS code, but not so well for native (c/c++, or binary files). Particularly, there are lots of different archs (32/64 bit Windows, several Linux archs etc), it means we have to either let users compile when install, or pre-build all the archs. Notice that CoffeeScript, TypeScript, and Babel are all implemented in JS, without any native dependency. You can’t install other natively compiled languages, for example Python/Ruby, with npm.
“Compile when install” is not really an option for us given the complicated procedure of getting OCaml and various opam libraries (particularly, on Windows).
Neko is just hard to be packaged properly on npm, and it is a needed, important dependency of Haxe because many haxe libraries uses a run.n. Loading ndll is non-trivial for npm hosted haxelib (have to set NEKOPATH).
I appreciate all the effort people have put. The npm-haxe repo is a work of clemos and damoebius, and it kinds of work for some (most?) work cases. If anyone want to improve that, discuss with them.
What about post-install scripting, to download and unpackage the correct archive?
This removes the necessity of either A.) packaging all architectures or B.) compiling it on-demand on the user’s system (which I understand, that gets a lot more complicated), but still requires Haxe to be able to operate as a modular package.
It is this part (operating properly once located in the directory) that I think would require more collaboration than a wrapper script.
@elsassph Are you aware what the issues are on Windows?
What do you mean by that? If you mean binary archives, they are architecture dependent, that means we have to pre-built for all OS/arch combinations. The current ones distributed in the download pages are not enough to cover all cases. But as far as I know, the “download and unpack” strategy is already used by the current npm-haxe module (and right, it doesn’t work on arm devices, for example).
@damoebius I think there’s a bit of misunderstanding about haxe npm: people are wondering whether it’s up to date, whether it supports all platforms, etc.
I also was confused at first with haxe-npm; I thought I had to install specific versions of haxe-npm to run specific versions of Haxe SDK.
But that’s not the case, haxe-npm will download locally the version you specify in package.json, so as it is, haxe-npm doesn’t need to be more “up to date” (unless it requires fixes/new features).
You can definitely use haxe with npm, as typescript.
But actually it doesn’t install neko, I think it could have it’s own npm package.
And I don’t know if haxelib works because I don’t use it
It might make sense to make 3.4.4 the default, now.
So based on our discussion so far, two things come up in regards to improving compatibility with NPM:
1.) Make it possible to use “neko” from an NPM environment
2.) Make it easier to access haxelibs from NPM
There are @types/<lib name> packages on NPM, that represent typescript types for libraries. What if the Haxelib server automatically published Haxe libraries under something such as @haxelib/<lib name>, using the same version tag? It would have to create a package.json for each library, and (ideally) haxelib or at least -lib would be able to find these libraries (though -cp node_modules/<lib name>/ works in a pinch)
EDIT: Please no one use this name prefix until we’ve discussed it more, since NPM does not allow you to re-release the same version tag, it’s important that we have things right and settled before we start using up repo names and tags
@damoebius Haxe npm surely needs to download neko as well, and possibly it should also have a cache mechanism to not re-download the same binaries all the time.
@singmajesty I think David has looked into publishing to npm; in fact it could very nicely line up with @back2dos’s haxeshim to transform the -lib automagically.
haxeshim and switchx are available through npm (only).
The haxe and neko binaries are reused between projects and it works on Mac, x64 Linux and x86 Windows - I don’t know if 32 bit is still a thing, but since Windows will run the binaries just fine, it seemed like the more defensive choice … if there’s a need to improve on this, feel free to open an issue.
That said, npm is just used as a distribution channel, because it’s practically ubiquitous. Beyond that, there’s literally no integration.
Using @haxelib/<lib name> in the manner described will be hard if not impossible. It’s certainly not an issue of just adding one class path. You want the extraParams.hxml to work correctly and you also need to deal with the fact that npm will install dependencies in a nested manner, so you will have to deal with that part too (because we don’t use require to load dependencies). Better yet, if you depend on @haxelib/foo and @haxelib/bar and both depend on @haxelib/boink, it’s installed twice and you have to pick one that works for both - if that’s possible at all. Simply put: the way node (and therefore npm) handles dependencies is not compatible with haxe, except in the most trivial cases.
Alternative: The registry accepts additional fields, so having a haxeDependencies field that simply contains the dependencies from the haxelib.json will work just fine. You can act on that configuration in a postinstall hook and also you won’t have to set up mirroring between haxelib and npm (although you can still add that later to increase availability).
I think it’s all solvable (that’s not like haxelib does a good job at handling conflicting transitive dependencies anyway) but the benefit isn’t clear and it’s generally a bit off topic.
Let’s keep it about having a solid way to install haxe+neko from npm
Of course it is solvable somehow. Just not by relying on npm to install the dependencies. I don’t see what haxelib’s inadequacies have to do with that
It’s my understanding that this is all about reducing friction for npm users. I don’t see this target audience accepting a solution that has no simple way to use 3rd party code. It makes sense to configure these dependencies in the package.json, because that meets general expectation - going against it will cause friction.
Sure, these are two separate problems. But a solution for just one of them doesn’t really solve anything at all at the bottom line.
Then let’s have a discussion (here?) on how to use npm to manage haxelibs, directly or indirectly. I think it could work - what problem do you see in npm dependencies resolution? Beside having to potentially choose one of several versions.
So I see a number of possible improvements that are coming up about haxelib for an NPM-based project:
Idea 1
Using haxelib install within the NPM-based project causes haxelib to set up the dependency in “node_modules”, with a fake package.json
Idea 2
Allow haxelib to be sensitive to an additional “package.json” field, specific to haxelib. Ideally, make it simple to integrate for npm install to cause haxelib to install its dependencies as well. Additionally (for bonus points) haxelib install should write to “package.json” with a hard-coded version, to simplify recreating the same environment
Idea 3
Not exclusive from the above two ideas, but improve haxelib so we can install in an NPM environment, and have it not prompt for the haxelib path, but presume that it will be saved under “node_modules”, or “haxelib_modules”, or some other dedicated path when working in this workflow
Idea 4
As mentioned previously, find ways to improve Neko to work as an installed tool within this environment
