-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Roadmap to Webpack Encore #7049
Comments
It's not clear to me: |
Would be nice for the stable version, but not mandatory. To be noted that some of this will break bc, so if we do it after the stable, will need to be done for 5.0. For example: Is it mandatory to have admin lte v3 to release sonata admin v4 stable? Not to me, it would be nice but not mandatory. |
If I remember correctly, Admin-lte v3 seems to be a huge change because it will use bootstrap 4 instead of 3. I'm ok to release the stable v4 in 1-2 month and to release the v5 at the end of the year. |
Im okay with not upgrading admin-lte for v4. This issue is about making changes that bring value and not blocking releases or try to upgrade a lot of things in a single PR. |
We have a problem with this dependency: Eonasdan dateTime picker It is installed here (previously it was on core-bundle), but the date form types are actually in https://github.com/sonata-project/form-extensions/tree/1.x/src/Type (they were previously on core-bundle too) We have at least 3 solutions here:
The only thing with the third option is that we need to configure webpack encore there too. Edit: To be noted that the wdyt? Maybe there are other options I didn't thought about. @sonata-project/contributors |
I have installed bootsratp 4 for the front of my project with webpack and I'm using "tempusdominus-bootstrap-4": "^5.1.2" with
and I'm rendering it with I don't know if this is helpful for your problem but I'm just pointing out that it works with the picker type |
What version of |
none |
Oh you replaced Still I don't know if all options of our base date time types are compatible with that package. (Also to be noted that we are still using bootstrap 3 here because of admin-lte v2). The problem that I am trying to point out is that we are installing a package that gives a features used in another library and that's a problem when trying to upgrade things. My fear about upgrading this package is this PR: sonata-project/SonataCoreBundle#149 Edit: Now that I see it, most of the changes comes from the fact that it is using bower and replacing a lot of files that are not ours. Adding a third option... |
can we maybe remove those options from |
That could be a good thing to try, but not sure about this: https://github.com/sonata-project/form-extensions/blob/1.x/src/Bridge/Symfony/Resources/views/Form/datepicker.html.twig If those form-extensions types are suposed to work standalone, I am missing something, because there is a coupling with some javascript but the bridge provides none. |
oops, I thought the templates were here, in that case I guess we should also override them (and not sure how would look like in |
If we remove those templates from the extension, how does it work when used standalone? Not sure about that. @sonata-project/contributors wdyt? |
A lot of the work required is already done or on PRs already opened. I just moved some tasks to second priority |
We might take all the first round in 4.0 and set 5.0 milestone for the second round :) |
IMO we should consider integration with webpack encore bundle in 4.0. Then other things from second round can be done in 4.x as experimental another encore build. |
I have listed what <script> tags we have in our templates, it will be a lot of work. Maybe not all will be complete for 4.0 |
For collection is use |
Looks nice to look at how they do it, but IMHO we should not ingrate dependencies that does not look well maintained, with not much activity, not stable release and so on... we could end up with the x-editable drama again. |
Sure! Just pointing out. not an actual suggestion. |
I didn't found any good plugin to check for license header in stylelint, do you know one? It should work in a similar way to https://www.npmjs.com/package/eslint-plugin-header but for stylelint. I saw a few, but not very well maintained or not working. |
@jordisala1991 I just discovered that the recent update of admin-lte in 3.x lost the import of the See What is the best way for us to add this in 3.x ? And in 4.x ? |
I think adding it at the end of
If it works, maybe you can add it to our docs? |
Not sure we have to add something to the doc, if I add it to the
I was wondering if it should be added to the |
Not sure how to handle it, I was thinking on deprecating the default css and javascript configuration now that we have only 1 file each. Maybe it can be on the template with a block to be overriden? |
👎 We should not load ANY third party dependency from an other host. We should load this font via |
I think there should be way to add simple css or js hacks to admin via config |
This was the way it was loaded before in the css
So adding
is just loading the font the same way in order to fix the BC-break introduce in 3.x with the admin-lte bump. In 4.x maybe we could do it here: https://github.com/sonata-project/SonataAdminBundle/blob/master/assets/scss/app.scss ? Or can we download the font and put them here: https://github.com/sonata-project/SonataAdminBundle/tree/master/src/Resources/public/fonts ?
@jordisala1991 wanted to deprecate the default config. |
For me, this was a security fix and no BR break. I don't want to use any stuff from google and respect the user privacy.
This is the way to go 👍 |
There was no information in the changelog about the removal, and the design is suffering from this removal.
I'm not familiar with this. |
IMO 2 options:
|
Can you do it ? :) |
I just did for master: #7131 Once that is approved, the fonts files can be backported to 3.x and the css necessary too. (on the merge back to master will be removed). |
I will split the remaining list into smaller issues. The integration with webpack encore is done, now it is time to improve what we have. |
Feature Request
We recently moved to NPM to handle all the dependencies of our code: #7034
First Round
components-font-awesome
for@fortawesome/fontawesome-free
(Upgrade to font awesome 5 #7133)The text was updated successfully, but these errors were encountered: