-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[WebProfilerBundle][TwigBundle] Compile assets #29537
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we go that way, the assets
folder should be ignored in the archive (through .gitattributes) as it should be purely a contributor thing (the bundles should use the final version).
@stof in less then 2 hour (including initial research / setup) ive replicated the tabs component successfully (it actually works): (i havent include the util classes yet, such as I think this is very viable, IMHO. Developing in PHPstorm is a joy, and i tend to take the extra compile step for granted. JS community would embrace this most like likely i guess. I was hoping @javiereguiluz can help in transferring the components etc., so we can do a clean-up/improvement round right away. Each component should define it's own vars at least, and perhaps we can reduce the no. of global/duplicate stuff scattered around. Ultimately that would ease the migration to maybe React/Vue components 😱 (but put on a diet; let's see :P) |
The new approach is ready to EOL the old one (i think we should). In theory we can now move everything per-case (ie. this PR can be merged as-is) and is 100% BC (ive only updated tabs in the profiler for now). |
Roland, thanks for working on this change. To give more context: as you said, during the SymfonyCon we talked about this. The current situation is not ideal (we have duplicated CSS/JS assets, the JS code is defined inside Twig code, etc.) This is slowing us down. It's not easy to do improvements in the toolbar or profile, and we're thinking about some cool changes to make them more useful (think about things like the dynamic filter added by Roland in 4.2). But don't worry about this change. We're not going to do useless changes and we're not going to complicate things for the community. We're very focused on improving things to provide more value to end users. Thanks! |
Agree. Im striving for the opposite here long-term. That said, i do like to introduce some technical/conceptual changes with this PR, in an effort to avoid never ending iterations.
--sf-some: x;
.sf-hidden {}
.sf-component .local {}
// component.css requires globals.css
--sf-component-some: --var(--sf-global);
.sf-theme-dark {
--sf-component-some: --var(--sf-dark);
}
.sf-component {
.local {
}
}
|
Shall we close here? |
i guess :} |
This is a quick POC how we can extract pure CSS/JS and compile a distribution, to be committed and used by the components.
The idea is to introduce somewhat of codestyle and modern stuff. I followed the webpack-encore-bundle setup in a new local
assets/
folder (without the composer constraint). cc @weaverryan this was fun 👍The goal is to provide a single source of truth and ease maintenance. And eventually allows us to move forward in a more modern way.
I've discussed some ideas with @javiereguiluz, but for now im aiming preserve BC fully and focus on the inventory first, sort of speak.
The missing step here is still a simple binary to copy the build files into the components under src/, e.g.