sync-by-unito[bot]
commented
1 month ago ➤ Charles Fannin commented:
@Callin Mullaney I apologize ahead of time if this is reiterating what you already know.
I spent some time reading through the provided links and gathering context.
Based on what I am reading; which is mentioned on the ticket, the maintainer of Twig-loader is very adamant on using webpack and not twig-loader to resolve paths. This is mentioned several times on several closed PRs on the twig-loader package.
Apparently resolving paths is possible in webpack but this is a bit out of my wheelhouse. I'm not confident I can extrapolate what truly needs to be done here.
But for what it's worth, I've added some Pros/Cons to the Ticket loosely based on what I have learned so far.
We are currently using a forked version (technically a fork of a fork) of twig-loader, which is for enabling Webpack to load twig files.
The reason we are doing so is that the original version does not have support for namespaces. The owner says that Webpack has the ability to parse paths and that instead of that loader working to add that support, we should leverage Webpack's ability to resolve paths. That may be true, so this story is to explore whether that is the case or whether we can offer an acceptable PR to twig-loader to allow for namespaces. Here are the resources:
https://github.com/zimmo-be/twig-loader/issues?q=is%3Aissue+namespace Fork that built in namespace support: https://github.com/AmazeeLabs/twig-loader Our fork that uses that but adds updates from original (eyeroll): https://github.com/fourkitchens/twig-loader
Enhancing twig-loader to support namespaces - Pros: - Provides a more integrated solution for projects heavily relying on Twig namespaces. - Potentially benefits the broader community if there's significant demand for namespace support. - Allows for a more seamless development experience when working with Twig templates. - Cons: - Requires maintaining a fork or getting changes merged upstream, which can be time-consuming and complex. - May introduce maintenance overhead if the original
twig-loaderis frequently updated. - The effort to implement and test the feature might be significant.Leveraging Webpack's Path Resolution - Pros: - More about configuration than maintaining custom code, reducing maintenance overhead. - Simplifies the setup for projects with straightforward namespace usage. - Avoids the complexity of modifying and maintaining a fork of
twig-loader. - Cons: - Might not provide as tight an integration with Twig's features for projects heavily relying on namespaces. - Requires understanding and configuring Webpack's resolution mechanism, which could be a learning curve for some teams. - May not address all use cases or scenarios where advanced Twig namespace features are needed.