Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Twig loader package #202

Open
evanmwillhite opened this issue Mar 16, 2021 · 1 comment
Open

Twig loader package #202

evanmwillhite opened this issue Mar 16, 2021 · 1 comment
Assignees
Labels

Comments

@evanmwillhite
Copy link

evanmwillhite commented Mar 16, 2021

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-loader is 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.

Copy link

sync-by-unito bot commented Jul 19, 2024

➤ 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Status: Backlog
Development

No branches or pull requests

3 participants