Is it being used somewhere?

[fefas]

Hey! This is just a question-issue.

I really enjoy the idea and I wanted to know if YAY is actually being used in some project.

Thanks!

[chris-kruining]

@assertchris uses it in https://preprocess.io/#/ for a I-wish-php-would-have-that library.

[marcioAlmada]

On the FOSS there is also @nunomaduro using it for https://php-plus.com

And some people often reach by email with things still in private state.

[nunomaduro]

Yeah - @assertchris and I are building https://php-plus.com. ⚗️

[anibalsanchez]

I'm using Yay and Preprocess. The objective is the port of a PHP source codebase between CMSs. So, we have Yay macros to produce the code for each CMS.

It works perfectly fine and I'm already packaging the results of the processing in real-world products for customers. No issues so far and the products are live and tested by third-parties. So, it has been a success ;-)

BTW: The current implementation of the processor is based on @nunomaduro Laravel Zero command line :-D.

[assertchris]

At first, I thought this thread was going to be 🤨, but now I see this thread is 😁

[marcioAlmada]

@anibalsanchez hey, I'm curious to know about how Laravel Zero command line was combined. Did you use it as a linker? :)

[anibalsanchez]

@marcioAlmada Yes. Yay and Preprocess are bundled together in a command-line powered by Laravel Zero.

The CLI is now stable and we are applying it in several projects. Right now, we are executing the command manually. We plan to create a CI/CD implementation to automate the processing.

We are processing projects with 4K files where performance is critical. In the beginning, it could take 1h of processing. After several iterations, optimizations, and running the Yay processor in Swoole threads, the processing time is down to 2-5' in an i7 HQ with 8 Cores. So, it is manageable.

Yay didn't require modifications, and we only added a tweak to Preprocess. We added a function to add Literal Macros (to generate the macros on the fly): anibalsanchez/pre-plugin-fast-mode@6f49a11#diff-99d427c9a032e85cf9d56c734a2a730dR27

[marcioAlmada]

@anibalsanchez perhaps you'd like to take a look here > 36e8191. We are usually able to expand entire symfony projects really quick even visiting the vendor folders... I can't see why the 1h processing time without parallelization unless there is a weird backtracking going on on somewhere in the tool chain 🤔

[assertchris]

@anibalsanchez @marcioAlmada before Pre (plugin) 0.12.0; each file would be re-processed every time (in dev). Since then, files are only "visited" if they've changed. Should be much faster now.

[assertchris]

If you're using macros that depend on an earlier version, you can alias 0.12.0 as:

"pre/plugin": "0.12.0 as 0.11.?"

...where 0.11.? is the version you currently need.

I'll be updating the Pre macros to use this new version in the next few weeks. Lots of work going into improving the plugin at the moment.

[anibalsanchez]

@marcioAlmada In our use case, we generate dynamically the macros. So, each processed PHP files can require to apply around 50 macros. The macros don't add new features to PHP, they are oriented to port the code between CMSs versions.

@assertchris Great, I'll keep an eye on the next updates.

Keep up the good work!