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.
|
6 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. |
@gmazzap @cabbey I see a lot of libraries written in TS but distributed already transpiled. How does that enforce anything?
In the case of PHP, there would not be a transpile step. The erased types would mainly be fancy syntax as hints to tools like IDEs.