Sanitize untrustworthy HTML user input (Symfony integration for https://github.com/tgalopin/html-sanitizer)
Symfony bundle integrating Flysystem into Symfony 4.2+ applications
Add composer install
Now that the logic "warm => dump => import + tree-shaking" is mastered, that would be easy to create a UX Router package.
Exactly my thinking as well :)
IMO we shouldn't care too much about importmaps for this PR.
My reasonning is that I think there are mostly two use cases for import maps (ie. two types of people using them):
1/ in dev environment it allows not to have to wait for webpack to build, meaning a faster iteration loop => we don't care that the whole translator is imported here, as long as it will work the same way when using Webpack.
2/ In prod environment, almost everyone with a slightly big app uses Webpack or another bundler. Webpack isn't only about building, it's also about productivity: many modules allow to inspect the code, to compile it, to provide DX tools, ... I generally compare it to the Symfony container being built: of course we could do without, but CompilerPass are hugely useful.
The only two cases where I can see someone using import maps in prod would be for small projects (=> fine to import the whole translator) or for projects having a large app but a tiny bit of front-end (in which case they most likely should just pass the translations from PHP as Stimulus values or similar).
I don't see a case where import maps are an issue, especially given how the DX is so good using the tree-shaking approach (you simply don't need to think about translations).
BTW I think a good tool to create in the future will be a Router ;)
Prepare CI
Merge pull request #1 from selency/prepare-ci
Prepare CI
Prepare CI
WIP
WIP
WIP
Upgrade to sF 6.2
Modernize the codebase + fix some wording
Merge pull request #15 from lyrixx/update
update
@symfony/mergers before spending time on the component, I'd love to have your input to see if we think it's a good idea to have such a component in Symfony.
I'd be totaly fine publishing it under a Selency name (I do think it's a useful package, especially with the new payloads introduced by https://github.com/symfony/symfony/pull/49138) but it doesn't have to be under Symfony namespace;
@Neirda24 IMO this is comparable to a security firewall: an initial check before the controller to ensure the request is OK (security wise & payload wise). I don't think it's an issue that the controller doesn't have control over the failing case, in both situation: one could easily implement a listener catching ValidationFailedException to display the page they want
@dunglas @soyuka perhaps instead of a subtree split in api-platform, the code could be put in Symfony as the OpenApi component (considering it'd need to be decoupled from apip to do so)?
I don't think apip is (currently) known for its reusable components, meaning the package would get more visibility in the Symfony organization. I'd be happy to update my PR here if that seems like a good idea.
@jakublech we actually started to do it manually, but it's very cumbersome. We repeated ourselves a lot, we weren't able to reuse parts of our definitions around, we couldn't store the documentation close to the code linked to it,...
Also, the component provides reusability capabilities, for instance :
class OpenApiBuilder extends BaseBuilder
{
public function paginatedCollectionSchema(SchemaConfigurator|ReferenceConfigurator|string $itemSchema): SchemaConfigurator
{
return $this->schema()
->type('object')
->property('items', $this->schema()->type('array')->items($itemSchema))
->property('pagination', Documentation::REF_SCHEMA_PAGINATION_DETAILS)
;
}
}