-
Notifications
You must be signed in to change notification settings - Fork 38
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
webpack v4 compatibility upgrade #12
webpack v4 compatibility upgrade #12
Conversation
So I have been banging my head against this thinking its been something to do with migrating to the hooks API (could still be an issue there, just got stuck somewhere sooner along the path it seems). I have determined that (possibly due to webpack-cli being moved out of core webpack?) the upgrade to v4 is "breaking" tests by not actually generating a build into the build directory anymore. In this branch, I have only updated webpack to v4 and commented all the other loaders and plugins out of the test webpack config, as well as the assertions within the generate-css spec file, and while mocha runs and the tests pass, there is no output to the filesystem. describe('HtmlCriticalWebpackPlugin Cases: Generate Critical CSS', () => {
const buildDirectory = path.resolve(__dirname, 'build');
describe('minimum configuration', () => {
it('should generate the expected critical inline <style> tag', (done) => {
webpack(webpackConfig, () => {
// const indexHtmlString = fs.readFileSync(`${buildDirectory}/index.html`, {encoding: 'utf8'});
// const indexHtmlDom = new JSDOM(indexHtmlString);
// const inlineStyleTags = indexHtmlDom.window.document.querySelectorAll('style');
// assert.equal(inlineStyleTags.length, 1);
// assert.equal(inlineStyleTags[0].getAttribute('type'), 'text/css');
done();
});
});
//etc
})
}) $ npm test
> html-critical-webpack-plugin@1.1.0 test /Users/owenbuckley/Workspace/github/forks/html-critical-webpack-plugin
> rimraf ./test/cases/**/build/** && mocha ./test/**/*.spec.js
spec webpackConfig { mode: 'production',
entry:
{ index: '/Users/owenbuckley/Workspace/github/forks/html-critical-webpack-plugin/test/cases/generate-critical-css/index.js',
main: '/Users/owenbuckley/Workspace/github/forks/html-critical-webpack-plugin/test/cases/generate-critical-css/main.js' },
plugins: [] }
HtmlCriticalWebpackPlugin Cases: Generate Critical CSS
minimum configuration
✓ should generate the expected critical inline <style> tag (428ms)
- should generate the expected critical <link> tag
- should generate the expected critical <noscript> tag
HtmlCriticalWebpackPlugin
webpack hooks
✓ HtmlCriticalWebpackPlugin has the required apply method
✓ HtmlCriticalWebpackPlugin has the required emit method
3 passing (433ms)
2 pending By comparison, using the $ ./node_modules/.bin/webpack-cli --config ./test/cases/generate-critical-css/webpack.config.js
Hash: 4d2d7501158ffb5ed2af
Version: webpack 4.1.1
Time: 94ms
Built at: 2018-3-12 14:19:20
2 assets
Entrypoint index = index.js
Entrypoint main = main.js
[0] ./test/cases/generate-critical-css/main.css 200 bytes {0} [built] [failed] [1 error]
[1] ./test/cases/generate-critical-css/main.js 101 bytes {0} [built]
[2] ./test/cases/generate-critical-css/index.css 226 bytes {1} [built] [failed] [1 error]
[3] ./test/cases/generate-critical-css/index.js 104 bytes {1} [built]
ERROR in ./test/cases/generate-critical-css/main.css
Module parse failed: Unexpected token (1:0)
You may need an appropriate loader to handle this file type.
| .card {
| background: none !important;
| border: none !important;
@ ./test/cases/generate-critical-css/main.js 3:0-20
ERROR in ./test/cases/generate-critical-css/index.css
Module parse failed: Unexpected token (1:0)
You may need an appropriate loader to handle this file type.
| .lazyload-wrapper .card-img {
| border-radius: 0 !important;
| min-height: 233px!important;
@ ./test/cases/generate-critical-css/index.js 3:0-21 |
I figured out the issue why webpack wasn't outputting files ☝️ it was because i had a JS style comment in index.css 😕 .fade-appear.fade-appear-active {
opacity: 1;
transition: opacity 600ms ease-in; //ms should match the value of transitionAppearTimeout
} changed it to This PR is now ready for review. Additional considerations as other PR(s) most likely:
|
Great work on this, @thescientist13 A few comments:
Regarding your other suggestions, I'm a yes to all of those. A caveat about point 1, though, we'll need to find out the minimum supported version of Node for Webpack v4 and ensure classes are supported. Or transpile. |
What will we do about backwards compatibility? My thinking is that we tell people to use the previous version. If you agree, perhaps include an update to README. Also, I think we should we bump the version to 2.0.0 in this PR. |
thanks for the feedback @anthonygore , I'll put some into this today. |
Made some updates, let me know your thoughts @anthonygore
I think this is probably just .a race condition and hitting the default mocha timeout, so I bumped the mocha timeout to
Good catch! I changed those instances to just normal hex colors
Not that I have a strong preference one way or the other, but the docs and guides I followed seemed to
webpack v4 dropped support for Node <= v4. and now supports >= 6, which has support for Made an issue for tracking all the misc. refactoring items unrelated to this PR - #13 |
Also, not sure if this is the PR we want to introduce mini-css-extract-webpack-plugin with, but I am happy to include it here. |
Unfortunately the failing test is not a race condition. When I inspected the outputted HTML, there's no style tag! I'm not sure why the tests don't correctly fail, either, they just timeout. I'm cool with CamelCase if that's a convention. All the rest is fine, too. |
Actually, I just tried to run the tests on the master branch and it's the same problem. I haven't investigated deeply, but I did try to log any errors from the API i.e.:
But there are no errors. Strange. |
@anthonygore |
I tried node versions 4, 6, 8 and 9....same problem with all |
@anthonygore will continue to investigate. For the record, I am using OSX. |
Yes, OSX for me too |
Hey @thescientist13, after your great work getting the docker environment created, I think we're almost ready to merge this. What I think needs to be done is:
[edit] Actually... I don't think we should merge this unless it includes mini-css-extract-plugin. Since EWTP is not going to be supported by Webpack 4, we'll have instant problems. What do you think? |
@anthonygore |
All set for review @anthonygore ! Question, should this be updated? Had a question about the
I'm not sure how much transpiling of node specific packages is needed in most use cases, but I think it's generally become standard practice to let consumers transpile if they need to, and let authors just publish the source. Let me know your thoughts! |
Related Issue
resolves #9 , to upgrade the project to support webpack v4
Summary
Started the process of upgrading to webpack v4. Got a couple expected errors from HtmlWebpackPlugin and ExtractTextWebpackPlugin each after upgrading webpack but was able to resolve those easily by upgrading them as well.
Changes
webpack@^4.0.0
(4.8.2) and installedwebpack-cli
, which is needed to run webpack from the command line nowcompiler.plugins
API tocompiler.hooks
API (only "main" change)asserts
accordingly based on newer observed behavior I saw (which I am taking for face value, but please feel free to suggest a different approach).engine
in package.json to `>=6.0.0"TODO
engine
in package.jsonMisc
Note: This since been resolved since this PR was through a correction in a CSS comment in index.css. webpack wasn't outputting build files as a result, hence the
ENOENT
error👇Resources
Here are some good links and docs I've found re: upgrading to v4 for plugins / loaders