[stage1] Haxelib replacement

[Simn]

Foreword

Issues in this repositories tend to get bogged down in long-winded discussions without much of a result. We would like to try a slightly different approach which is outlined here: https://github.com/HaxeFoundation/haxe-evolution/wiki/Haxe-Projects

We are in Stage 1 here, which means that comments should be short and to the point as mentioned in the document. If you want to discuss the procedure, please open a separate issue.

Now on to the actual project.

---

Haxelib replacement

Project lead: Simn
Due date for stage 1: 2017-10-14 (2 weeks)

We are looking to replace haxelib with a better package manager solution.

Please share your ideas and concerns in a concise manner. Please also +1/-1 individual comments that you agree/disagree with.

[Simn]

The Haxe compiler should not have to call a separate tool to obtain the information required for compilation.

[kevinresol]

The Haxe compiler should not have to call a separate tool to obtain the information required for compilation.

That means the compiler should be able to transform -lib tags into non-lib tags on its own, with the resolving logic being simple yet generic.

[elsassph]

Criteria:

• semver dependency management, and solution to handle conflicts as we can have only one version of a lib,
• global cache and local libs similarly to npm/yarn,
• support for git / file dependencies.

[damoebius]

NPM isn't enough ?

[ibilon]

The user should be able to use an alternative package manager (without making change to or replacing the haxe exe).

[ousado]

The compiler should expose an interface for frontends like CLIs, IDEs, vscode-style language servers, and so on.

[ousado]

Whatever ends up as standard mechanism to invoke the compiler for one-shot compilations must be very fast, there should be no noticeable difference to invoking the compiler directly (in other words start-up times like that of nodejs or even the JVM are out of the question)

[ousado]

The standard mechanism to invoke the compiler will be a first point of contact for newcomers to the language. As such it should provide an outstanding user experience and documentation can't be an afterthought.

[ibilon]

We shouldn't change the current workflow and so not introduce any steps between changing a hxml and running it/doing a haxe command by hand.

[ibilon]

A migration plan is required:

• what happens to the already installed libraries? do they need to be reinstalled?
• do we keep the haxelib online repository as is? if not what about usernames?

[ousado]

Beyond building projects the standard mechanism to invoke the compiler should provide a standardized way to run other common tasks like tests, benchmarks, updating dependencies, etc. (much in the spirit of cargo).

[ibilon]

haxelib.json should be extended, proposed new fields (non exhaustive):

• repository field (to go with the current website field)
• listing the metas/defines of the library
• haxe version compatibility

[kevinresol]

That means the compiler should be able to transform -lib tags into non-lib tags on its own, with the resolving logic being simple yet generic.

Because -lib is the only thing that cannot be "consumed directly" by the compiler.