Closed n-rodriguez closed 6 years ago
For example, to load FontAwesome :
// FontAwesome
$fa-font-path: "~@fortawesome/fontawesome-free/webfonts";
@import '~@fortawesome/fontawesome-free/scss/fontawesome';
@import '~@fortawesome/fontawesome-free/scss/solid';
@import '~@fortawesome/fontawesome-free/scss/regular';
and the content of '~@fortawesome/fontawesome-free/scss/regular'
(for example) :
https://github.com/FortAwesome/Font-Awesome/blob/master/web-fonts-with-css/scss/regular.scss
For me the diff is clearer with just the keys on the left.
2,27c2,5
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-brands-400.eot",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-brands-400.svg",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-brands-400.ttf",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-brands-400.woff",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-brands-400.woff2",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-regular-400.eot",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-regular-400.svg",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-regular-400.ttf",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-regular-400.woff",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-regular-400.woff2",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-solid-900.eot",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-solid-900.svg",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-solid-900.ttf",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-solid-900.woff",
< "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/fa-solid-900.woff2",
< "_/_/node_modules/blueimp-gallery/img/error.png",
< "_/_/node_modules/blueimp-gallery/img/error.svg",
< "_/_/node_modules/blueimp-gallery/img/loading.gif",
< "_/_/node_modules/blueimp-gallery/img/play-pause.png",
< "_/_/node_modules/blueimp-gallery/img/play-pause.svg",
< "_/_/node_modules/jquery-ui/themes/base/images/ui-icons_444444_256x240.png",
< "_/_/node_modules/jquery-ui/themes/base/images/ui-icons_555555_256x240.png",
< "_/_/node_modules/jquery-ui/themes/base/images/ui-icons_777620_256x240.png",
< "_/_/node_modules/jquery-ui/themes/base/images/ui-icons_777777_256x240.png",
< "_/_/node_modules/jquery-ui/themes/base/images/ui-icons_cc0000_256x240.png",
< "_/_/node_modules/jquery-ui/themes/base/images/ui-icons_ffffff_256x240.png",
---
> "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/application.scss",
> "_/_/node_modules/@fortawesome/fontawesome-free/webfonts/jalis.scss",
> "_/_/node_modules/blueimp-gallery/img/application.scss",
> "_/_/node_modules/jquery-ui/themes/base/images/jalis.scss",
36d13
< "concerto_back_office/application.css.map",
40d16
< "concerto_back_office/devise.css.map",
44d19
< "concerto_espagne/application.css.map",
48d22
< "concerto_france/customer.css.map",
52d25
< "concerto_france/devise.css.map",
56d28
< "concerto_france/jalis.css.map",
60d31
< "emails/default.css.map",
64d34
< "emails/newsletters/v2.css.map",
68d37
< "emails/transactional/commercial.css.map",
72d40
< "emails/transactional/global.css.map",
76d43
< "emails/transactional/global_with_images.css.map",
90c57,58
< "vendor/images/concerto/halo.png",
---
> "vendor/images/concerto/jalis.scss",
> "vendor/images/concerto/logos/application.scss",
97d64
< "vendor/images/concerto/logos/spanish-site.png",
119,127c86,87
< "vendor/images/inspinia/chevron-right.png",
< "vendor/images/inspinia/patterns/header-profile-skin-1.png",
< "vendor/images/inspinia/patterns/header-profile-skin-2.png",
< "vendor/images/inspinia/patterns/header-profile-skin-3.png",
< "vendor/images/inspinia/patterns/header-profile.png",
< "vendor/images/inspinia/patterns/shattered.png",
< "vendor/images/inspinia/toggle_check.png",
< "vendor/images/jalis/deco1.png",
< "vendor/images/jalis/deco2.png",
---
> "vendor/images/inspinia/application.scss",
> "vendor/images/inspinia/patterns/devise.scss",
129,135d88
< "vendor/images/jalis/fd_ann1.jpg",
< "vendor/images/jalis/fd_ann2.jpg",
< "vendor/images/jalis/fd_footer.png",
< "vendor/images/jalis/fd_footer2.jpg",
< "vendor/images/jalis/fd_header.jpg",
< "vendor/images/jalis/fd_select.png",
< "vendor/images/jalis/fd_vendre.jpg",
137,139c90
< "vendor/images/jalis/ico_cadenas.svg",
< "vendor/images/jalis/ico_fb.svg",
< "vendor/images/jalis/ico_uk.svg",
---
> "vendor/images/jalis/jalis.scss",
@n-rodriguez It seems to me the @fontawesome
assets are no longer being identified and output.
But from what I see in the diff, perhaps @fortawesome/fontawesome-free/webfonts/application.scss
is not actually being processed. At least, its @imports
probably aren't processed.
Empirically I suspect that this is only a problem for @fontawesome
because it is in node_modules
.
Can you confirm that you only changed babel
. For example, did you also change some babel plugins or the scope/files the babel operates on?
This is an interesting problem and I want to help you fix your build. However at this point I suspect it is upstream of resolve-url-loader
.
Can you confirm that you only changed
babel
. For example, did you also change some babel plugins or the scope/files the babel operates on?
I did a yarn upgrade
so the diff is quite big but I know that the issue started with the Babel upgrade.
For example, did you also change some babel plugins or the scope/files the babel operates on?
No other change than yarn upgrade
(the code and the webpack config are the same).
Wow that could be anything @n-rodriguez.
Welcome to the typical user-experience for yarn upgrade
. Somewhere someone will not respect semver and will make a breaking change. Moreover you have a major change to at least one package (i.e. babel
), so all bets are off.
I think you need to roll back your changes and take it a package at a time and find the minimum break. For example, revert the changes to postcss
and cssnano
that I see in your diff.
Right now I don't see a basis to blame resolve-url-loader
. I would think that if the .scss
was being compiled then the url()
would appear in your output and resolve-url-loader
and/or webpack would complain if there are any problems.
Welcome to the typical user-experience for
yarn upgrade
^^
Moreover you have a major change to at least one package (i.e.
babel
), so all bets are off.
That's what I thought.
I think you need to roll back your changes and take it a package at a time and find the minimum break.
I really think it's related to Babel. I make progressive upgrades and the first broken CI was after the Babel upgrade. Postcss and CSSnano were upgraded after Babel (I thought it would help to solve the issue)
Right now I don't see a basis to blame
resolve-url-loader
. I would think that if the.scss
was being compiled then theurl()
would appear in your output andresolve-url-loader
and/or webpack would complain if there are any problems.
Thanks for the clarifications!
Please let me know if you solve this @n-rodriguez or if I can help further. Best of luck.
Please let me know if you solve this @n-rodriguez or if I can help further. Best of luck.
Ok! Thanks for your help!
Please let me know if you solve this @n-rodriguez
Hi there! The last Babel upgrade (7.1.2) has solved the issue :)
Hi there!
I "think" there is an issue with the latest release of Babel. The generated
manifest.json
is broken :Before the upgrade :
After the upgrade :
I can't say if the issue comes from this very specific lib as there's so many JS libs involved here, but if you look at the generated
manifest.json
the very first lines are about FontAwesome and they differ a lot from one file to the other.