# Questions and Problems with the haxe-php target
**URL:** https://community.haxe.org/t/questions-and-problems-with-the-haxe-php-target/2736
**Category:** Haxe
**Tags:** haxe-php
**Created:** [October 25, 2020, 10:58am UTC](https://community.haxe.org/t/questions-and-problems-with-the-haxe-php-target/2736 "2020-10-25T10:58:50Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@flammehawk](https://community.haxe.org/u/flammehawk)
#### Post date: [October 25, 2020, 10:58am UTC](https://community.haxe.org/t/questions-and-problems-with-the-haxe-php-target/2736/1 "2020-10-25T10:58:51Z")
Greetings,
currently I’m a PHP + JS Fullstack Developer and I’m at the moment evaluating if I maybe should use Haxe for some of my private projects.
The language in itself seems nice, so that is a big Plus for it.
But the big But that speaks against it is are some things:
1. First of all the PHP code that gets generated.
2. Integration of Composer packages
3. Project Structuring
> **Screenshot**
>
> 
I will still give Haxe a try and see how far I get with it.
---
### Author:  [@ablum](https://community.haxe.org/u/ablum)
#### Post date: [October 25, 2020, 11:39am UTC](https://community.haxe.org/t/questions-and-problems-with-the-haxe-php-target/2736/2 "2020-10-25T11:39:12Z")
regarding generating `index.php` there are two options: either use `-D php-front=notIndex.php` which will put Haxe’s entrypoint into `notIndex.php` which would still be accessible and launch your Haxe `main()` function, so probably not the best option. or you can just replace `-main mycompany.myproject.MainClass` with `mycompany.myproject.MainClass` in your `.hxml` or command line options and Haxe will generate `lib` folder but not overwrite your index.php.
if you use `-D php-prefix=App` you are telling Haxe to put all generated classes below namespace “App”. if you want to have `\Haxe\Php`, you will have to use `-D php-prefix=Haxe/Php` instead.
I don’t use composer packages, so I can’t say anything about that. I usually try to use pure Haxe stuff, so I wrote my own libraries.
as far as externs go you only need to write externs for classes that you use and you can limit your externs to what you actually want to use. that might reduce the number of externs you need, but that depends on your usecase.
Haxe’s VSCode plugin comes with support for `.hxml` file format.
I usually have multiple different `.hxml` files, some for building, some for display / completion support and some for testing.
to build the full project with multiple targets I often add a `build/Build.hx` that executes compilation calls via `Sys.command`.
you might also be able to use one big `.hxml` file with `--each / --next` sections.
---
### Author:  [@RealyUniqueName](https://community.haxe.org/u/RealyUniqueName)
#### Post date: [October 25, 2020, 11:56am UTC](https://community.haxe.org/t/questions-and-problems-with-the-haxe-php-target/2736/3 "2020-10-25T11:56:46Z")
> Question: Is their a way to Disable this behavior? So that I can generate my own Index.php and handle the bootstraping myself? This would make it easier to use existing PHP frameworks together with haxe
You can specify your “entry class” directly instead of specifying `--main` compiler argument:
```haxe
# instead of
--main Main
# do this:
Main
```
In this case “index.php” won’t be generated and you’ll have to create an auto-loader by yourself.
However it should be sufficient to just include haxe-generated “index.php” somewhere in your own “index.php”.
You can also use composer’s capabilities to load classes, an example of which you can see in this video: [https://www.youtube.com/watch?v=OkyMPkUEZxo](https://www.youtube.com/watch?v=OkyMPkUEZxo)
> The haxe lib files that get generated Why are they situated in the same Namespace as my Application if I use the -D php-prefix=App compiler flag?
Due to the nature of Haxe libraries there’s no reliable way to distinguish if `my.pack` package comes from your project or from a 3rd-party library at the generation step of compilation.
As a workaround you can compile a library separately from your project and then refer to library’s types through externs.
I agree this is not convenient and can be improved. Feel free to propose any ideas for discussion.
> Someone already made the effort to build a composer Package for it [https://github.com/cedx/haxe.php](https://github.com/cedx/haxe.php)
> Maybe we could have a compiler Flag that makes use of that package instead while building the Application like -D php-composer=true something Like that flag could be used for NPM as well.
You can use a compilation argument `--macro exclude("pack")` to prevent any types in `pack` package from generating php code.
> would it be an Option to check if a Composer Package already includes External definitions for its classes?
If extern definitions are already provided somewhere, all you need to do is to add a classpath of those externs. For example if you have a composer package “my-lib”, which contains extern definitions in a subdirectory “haxe-externs”, you just need to add this to hxml or compilation arguments: `--class-path vendor/my-lib/haxe-externs/`
> Currently we define our targets per CLI arguments or per .hxml file
> But that makes it hard in my eyes to define a Project with multiple Components Like One part is the Backend and One part is the Frontend. could we per chance maybe define this instead of a custom file format with either an .xml file or even Json/yaml file with a corresponding Schema definition so that It gets more readable and maybe even gives better integration with IDE plugins since they don’t need to read a custom format and write their own parser but could use existing ones.
We have discussions about a project file format from time to time, but have not come to consensus yet. Some Haxe frameworks solve this issue with their own project formats. There’s also a separate package manager, which you may find interesting: [Lix](https://github.com/lix-pm/lix.client)
---
### Author:  [@flammehawk](https://community.haxe.org/u/flammehawk)
#### Post date: [October 25, 2020, 1:00pm UTC](https://community.haxe.org/t/questions-and-problems-with-the-haxe-php-target/2736/4 "2020-10-25T13:00:27Z")
First of all thank you both for answering.
> [@RealyUniqueName](#):
>
> ```haxe
> # instead of
> --main Main
> # do this:
> Main
>
> ```
That already helps a lot
> [@RealyUniqueName](#):
>
> You can use a compilation argument `--macro exclude("pack")` to prevent any types in `pack` package from generating php code.
This is as well help full, just leads me to an issue with the Haxe Std it seems like their is no Root Package for it which results in not being able to exclude it in full using `--macro exclude("pack")` But that is something I should probably report inside a gh issue
And Lix realy looks interesting I will probably give it a try.