|
Top-level
@ramsey @cabbey It would be really great if transpiling would be self-hosted. Imagine you require a library via Composer. When pulling the code, Composer recognizes it needs transpiling, so it does it and puts the transpiled code in the vendor folder. If transpiling fails, Composer installation fails. This is not the same of Psalm/PHPStan, even if you could achieve something similar with a Composer plugin that requires the tool and run it on installation. 7 comments
 @ramsey @cabbey TS libs shared transpiled is not TS fault. For PHP, my point is that erased types could be useful if they would be only usable in a different format that would require "check + erasure" before being consumed by the engine. People could still distribuite "already erased" version of their code, but that's on them. Those who distribuite the non-erased version would force consumers to do that step. And if Composer could do it on install, that would require no change on devs workflow @ramsey @cabbey Imagine the scenario. There's a new .phps format that allows advanced types, generics, etc. The engine can *not* consume it. Composer recognizes it and do erasure (the engine provides means to do it). If composer.json requires a library that "provides" types checks, Composer will use that library to check the code before erasure. This would have no impact on people who do not want to type-check, but would empower a lot people who want to use advanced types, etc. |
Gregory's Server
@ramsey @cabbey That hypothetical plugin could run the SA tool when the corresponding configuration file is found. But we have several SA tools, and they don't have the same format for comments/attributes. Nor they have the same funcionalities. Something officially defined by the PHP project would allow Composer to implement this check-then-erase flow on installation, ensuring anyone using a lib would need to go through the static analysis step.