Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 24 2021 12:15
    cedx commented #68
  • Dec 24 2021 11:35
    cedx opened #172
  • Dec 20 2021 14:22
    andraaspar closed #169
  • Dec 20 2021 14:22
    andraaspar commented #169
  • Dec 16 2021 09:06
    cedx closed #170
  • Dec 16 2021 09:06
    cedx commented #170
  • Dec 16 2021 06:37
    anissen closed #171
  • Dec 16 2021 06:37
    anissen commented #171
  • Dec 16 2021 02:54
    kevinresol commented #171
  • Dec 16 2021 02:49
    kevinresol commented #170
  • Dec 16 2021 02:44

    kevinresol on v15.11.6

    (compare)

  • Dec 16 2021 02:44

    kevinresol on master

    15.11.6 (compare)

  • Dec 15 2021 19:28
    anissen opened #171
  • Dec 15 2021 17:15
    cedx opened #170
  • Dec 15 2021 08:52
    kevinresol closed #168
  • Dec 15 2021 08:52

    kevinresol on master

    Closes #168 15.11.5 (compare)

  • Dec 15 2021 08:52

    kevinresol on v15.11.5

    (compare)

  • Dec 10 2021 12:55
    back2dos commented #169
  • Dec 07 2021 17:11
    andraaspar commented #169
  • Dec 07 2021 17:05
    andraaspar opened #169
Gabriel Hayes
@piboistudios
Completely uninstall lix (and by this I mean I ran npm uninstall and also deleted the cmds/sh/scripts for Haxe out of npm folder), install haxeshim, delete the cmds/sh/scripts again (Lix tries to install these as well, because as you said it includes haxeshim), then install lix, and it built
Oh I just now saw your second message. I'll open an issue
Ben
@benmerckx
Could this be considered for the next lix release? lix-pm/haxeshim#71
Use case for me: I'd like to update https://github.com/benmerckx/watch to have a runnable main to be able to do lix watch build.hxml
Juraj Kirchheim
@back2dos
it's available in 15.11
the CI via travisci.org is gone and when I try to add the repo on travisci.com, it's not there \o/
image.png
Ben
@benmerckx
Thanks :D It works for me now!
Gene Pavlovsky
@gene-pavlovsky
Hey guys, I have a question about --haxelib-url.
In our project, we are getting most of the dependencies from a private haxelib repo.
They were installed using lix install --haxelib-url ...
But some libs are installed from github.
When running lix download, the subdeps of those libs are downloaded from the public haxelib repo, which is undesirable in our case.
Is there some way to tell lix to use the private haxelib url in this case?
Perhaps this option can apply to lix download?
Juraj Kirchheim
@back2dos
hmm ... do the download directives look right?
Gene Pavlovsky
@gene-pavlovsky
Which ones?
Gene Pavlovsky
@gene-pavlovsky
Running lix download later downloads the lib from github, and (I guess predictably) the sub-dependencies from the public haxelib server
I tried
lix install --haxelib-url http://host:port gh:gene-pavlovsky/haxe-checkstyle#4198dfcebdb6d08d41805e60e9a145b2c9949aed
And the hxml file generated is the same as without the option (perhaps predictably)
Just for fun I also tried
lix download --haxelib-url ...
And it works same as
lix download
Again, I guess predictably
Any solution for this conundrum, besides modifying the dependencies of the lib on github, or packaging that lib and deploying it to the local haxelib server?
Juraj Kirchheim
@back2dos
lix download should not be resolving any dependencies
only lix install deals with dependencies
so it's when installing checkstyle, that its dependencies are specified in their respective hxmls
you can, for example, reinstall those manually from your haxelib server
Gene Pavlovsky
@gene-pavlovsky

you can, for example, reinstall those manually from your haxelib server

This idea crossed my mind, although it's a less than ideal solution. The project itself doesn't really care about these sub-dependencies, so it would be nicer if they don't have to be in the project's haxe_libraries.

I think that logically, when one installs a lib from github, with --haxelib-url specified, the haxelib url should be still honored / stored in the lib's hxml file, so that if the lib's sub-dependencies come from haxelib, they would come from the specified one. What do you think?
Juraj Kirchheim
@back2dos
yeah, that'd make sense ... your other statement does not, though ^^
every project effectively cares about locking transitive dependencies ... this only becomes apparent when they're not locked :D
Gene Pavlovsky
@gene-pavlovsky
Yes but if we're locked to a particular version of lib A, that version will never change, doesn't that mean that by locking it to that version, we also automatically lock the transitive deps?
Anyway since you think the former makes sense, I made an issue on github
Peter Achberger
@Antriel
I'm getting hit by lix-pm/lix.client#163, curious. :D
Kevin Leung
@kevinresol
What version?
Peter Achberger
@Antriel
Not sure which I had before, a few months old one. But it did the same when I updated to your today's version right after.
The error makes no sense to me, it's as if it was compiled without hxnodejs right? But how could that be, when it's just JS file, it's not compiled locally or is it?
Kevin Leung
@kevinresol
I compiled it locally, something must be wrong
Let me try it again tomorrow
Peter Achberger
@Antriel
The same happened on the old version too though. Just not sure which version it was.
No hurry in any case. :)
Kevin Leung
@kevinresol
Can you please try again with v15.11.6?
Peter Achberger
@Antriel
Worked, thanks. :)
Gabor Varadi
@varadig
There is any solution to lock pm's version when update one of them?
Emugel
@emugel
do you mean the lix --flat option?
Peter Achberger
@Antriel
Looking into adapting my Haxe build too to run as npm lib, inspiring myself with Lix setup. I wonder, why does Lix use ncc? Purely for minification?
Peter Achberger
@Antriel
Also, if anyone has any hints regarding actually publishing to npm I would be grateful. Planning on having main lib and bunch of smaller tools as separate libs, not sure about multi/mono repo for that, or even naming conventions. :D
Juraj Kirchheim
@back2dos
lix has a number of dependencies and there are advantages to bundling them for distribution ... 1. faster installation (only one package with tree shaken dependencies included) meaning faster CI 2. all users always get the same code 3. it doesn't break if some (possibly transitive) dependencies are removed from the registry 4. it executes faster (in part due to the minification, in part due to the fact that there are no more require calls)
Peter Achberger
@Antriel
Great points. Something to consider.
In my case the sublibraries would have relatively big npm dependencies, such as aws stuff.
So ncc is about taking the main lib, and its npm dependencies, and merging that into single js, to achieve all that?
That could be viable approach for the less monstrous dependencies that are probably gonna be used often. Just not sure if it's considered a good practice, as it won't link to the dependencies in npm, and might miss security issues and disallows users forcing newer version if they want to.
Peter Achberger
@Antriel
Any hint for achieving at least top-level JS code completion?
Juraj Kirchheim
@back2dos
completion om what? and where? ^^
Peter Achberger
@Antriel
I meant completion for the JS exported from Haxe, to be used from other JS projects.
Juraj Kirchheim
@back2dos
hmm ... I kinda expected that to work ^^
Kevin Leung
@kevinresol
genes would be more complete I suppose