CPP-2230: upgrade to Webpack 5 #1002
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
apaleslimghost
force-pushed
the
webpack-5
branch
from
f9f2196 to
c6df9f9
Compare
apaleslimghost
force-pushed
the
webpack-5
branch
from
c6df9f9 to
e13d952
Compare
apaleslimghost
force-pushed
the
webpack-5
branch
2 times, most recently
from
688ffb5 to
cf18e50
Compare
apaleslimghost
requested a review
from ft-dependency-auto-merger
as a code owner
apaleslimghost
force-pushed
the
webpack-5
branch
from
9fc3c10 to
4be2c43
Compare
apaleslimghost
changed the title
|
hmm. the build is failing because |
not needed in webpack 5
also remove disabling cssnano's reduceInitial because we don't support ie11
…t default browsers `defaults` is browserslist best practice and is slightly more lenient than our current browser support
our browser support long ago outpaced how modern our CSS is, and browsers no longer use vendor prefixes for new features.
apaleslimghost
force-pushed
the
webpack-5
branch
from
4be2c43 to
0b2a87b
Compare
main webpack package ships its own types now
ivomurrell
approved these changes
Oct 22, 2024
| @@ -45,42 +46,21 @@ export class PageKitSassPlugin { | |||
| // Disable formatting so that we don't spend time pretty printing | |||
| outputStyle: 'compressed', | |||
| // Enable Sass to @import source files from installed dependencies | |||
| includePaths: ['bower_components', 'node_modules', ...this.includePaths] | |||
| includePaths: [ | |||
| 'bower_components', | |||
There was a problem hiding this comment.
thought: probably safe to remove this as a path at this point 😄
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
updates Page Kit's Webpack plugins to support Webpack 5. not backwards compatible with Webpack 4; most apps will be able to update without changing their config (although there are some things like
raw-loaderin use that v5 has more modern ways of doing that would be good to adopt).i've tested this with the
kitchen-sinkexample andnext-articleand everything seems to be working. it probably warrants more testing. it's a little annoying to link everything together to test locally; as well as the Page Kit packages you need to link the app to Page Kit's installs of at leastwebpackandreact/react-dom.webpack 5 breaking changes apps need to be aware of
exportsspecifier inpackage.jsonWebpack 5 is strict about not importing things that aren't exported inexports. this may require code changes in packages and/or apps to export everything that should be and import things correctly.next-articleimports@financial-times/custom-code-component/dist/custom-code-component.js, but that package doesn't include that entrypoint in itsexports(it exports., the top-level import, pointing that at the filedist/custom-code-component.js, which isn't visible outside the package).next-articlewon't build with Webpack 5 without changing thatimportto@financial-times/custom-code-component.spicy changes i'm making in this PR
-webkitprefixed properties supported by every browser; i have verified via Github search that we never use any of these properties unprefixed. this will eventually allow us to move away from PostCSS, speeding up our builds somewhat.@babel/preset-envfrom attempting to codify our browser support to just using Browserslistdefaults.defaultsis industry best practice, and slightly more lenient than our current browser support policy. this speeds up our build and reduces bundle size (by reducing how much syntax we need to compile), and reduces maintenance burden of updating our Browserslist config when our browser support policy changes.