Skip to content
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

Build: Add pragma check webpack plugin for server side rendering #1801

Merged
merged 1 commit into from
Jan 11, 2016

Conversation

ehg
Copy link
Member

@ehg ehg commented Dec 18, 2015

Closes #1594

Add a webpack plugin, for the client bundler, that:

  • Scans module sources for the ssr-ready pragma
  • Scans dependencies of these modules, and checks that they also have the ssr-ready pragma. Adds a webpack compilation error if not.

Did look like this, now looks like #1801 (comment)

screen shot 2015-12-17 at 19 20 47

TODO:

  • Better error messaging
  • Decide whether to bail on error
  • Some profiling on how this affects build performance (it subjectively feels it doesn't add much)
  • Remove test pragmas before merge

To test:

  • make run
  • Add /** @ssr-ready **/ to a file
  • Watch as the plugin reports unsatisfied constraints for that file's dependencies, and bails
  • Add the pragma to the listed dependencies, until make run doesn't error

@ehg ehg self-assigned this Dec 18, 2015
@ehg ehg added this to the Themes: Showcase M3-LoggedOut milestone Dec 18, 2015
@mtias
Copy link
Member

mtias commented Dec 18, 2015

Nice :)

@ehg
Copy link
Member Author

ehg commented Jan 7, 2016

Decided to bail the make run process if a pragma check error is found, this may be kind of annoying when encountered, but it's not going to happen too often at first. We can always investigate injecting something like alert( 'SSR errors' ) later, if necessary.

Currently looks like:

screen shot 2016-01-07 at 16 16 56

@ehg
Copy link
Member Author

ehg commented Jan 7, 2016

/cc @mcsf for a pre-'Needs Review' review :)

@ehg ehg force-pushed the add/webpack-ssr-checker branch from c03c9bf to ae0f329 Compare January 7, 2016 16:23
@ehg
Copy link
Member Author

ehg commented Jan 7, 2016

Some profiling on how this affects build performance (it subjectively feels it doesn't add much)

It doesn't seem to adversely affect build perf. I ran a few tests vs master, and the build times were pretty similar — this PR being faster for some tests, slower for others…

@ehg ehg added [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. and removed [Status] In Progress labels Jan 8, 2016
@ehg ehg force-pushed the add/webpack-ssr-checker branch from 2d643e8 to 7a80f51 Compare January 8, 2016 15:50
@ockham
Copy link
Contributor

ockham commented Jan 8, 2016

DevX concern -- if I screw up SSR and forget to restart Calypso, how will I know I messed up? Shouldn't there be some test that also fails? (In order to e.g. prevent merges via CircleCI.)

@ehg
Copy link
Member Author

ehg commented Jan 8, 2016

DevX concern -- if I screw up SSR and forget to restart Calypso, how will I know I messed up? Shouldn't there be some test that also fails? (In order to e.g. prevent merges via CircleCI.)

The make run process will fail, so hopefully you'd notice that. If you didn't, and there's a dependency error, it should be caught by make test's build rule dependency, so will error in CircleCI. If it's a more subtle mess up, #2240 will catch most renderToString errors, also in CircleCI.

@ehg
Copy link
Member Author

ehg commented Jan 8, 2016

The make run process will fail

Noting that we'll only fail it here if, say, a dependency not marked as ssr-ready is included in one that is. The purpose is to both document what modules we have deemed SSR-ready, but also to provide information and visibility when a 'risky' dependency is added.

It doesn't do anything clever, so won't catch any SSR-incompatible code errors. Maybe we could check for stuff like window being used and warn, but it's a bit of a rabbit hole.


module.dependencies.forEach( function( dep ) {
// If the module is compiled through babel, we can be pretty sure it's our own module, not from npm.
if ( dep.module && /babel-loader/.test( dep.module.request ) &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indexOf instead of the RegEx 'cause it's probably faster? </nitpick>

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure :) lodash's includes should be fast enough: https://github.com/lodash/lodash/blob/3.10.1/lodash.src.js#L6707

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

48ea69f

@ockham
Copy link
Contributor

ockham commented Jan 8, 2016

Looks good -- nitpicks aside :-)

I don't really have a clue about webpack, but I was just wondering if we were duplicating module tree traversal (since I guess webpack needs to traverse the module tree for compilation anyway)? And if there was a way to just tack onto that on its way bottom-up, setting a per-module SSR flag, and check immediate child modules for the presence of that flag...

Anyway, better to have a check soon than to spend too much time over-engineering. Feel free to merge 👍

if ( dep.module && /babel-loader/.test( dep.module.request ) &&
dep.module._source &&
dep.module._source._value.indexOf( SSR_READY ) === -1 ) {
compilation.errors.push( PLUGIN_TITLE + ': ' + module.rawRequest + ', dependency ' + dep.module.rawRequest + ' is not ' + SSR_READY );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want a brief explanation of the SSR acronym in the output.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want a brief explanation of the SSR acronym in the output.

Ignore, I now see the next line of output 👍

@seear
Copy link
Contributor

seear commented Jan 11, 2016

Am I right in thinking that the scanning algorithm means we can be looking for the pragma in the same module over and over again if it happens to be often used as a dependency often? If so we could cache results, but that is probably unnecessary complexity at the moment.

@ehg
Copy link
Member Author

ehg commented Jan 11, 2016

Am I right in thinking that the scanning algorithm means we can be looking for the pragma in the same module over and over again if it happens to be often used as a dependency often? If so we could cache results, but that is probably unnecessary complexity at the moment.

Yes, good point. I'll see what happens perf-wise when we have more pragmas.

@seear
Copy link
Contributor

seear commented Jan 11, 2016

Looks good 👍

@ehg
Copy link
Member Author

ehg commented Jan 11, 2016

Removed test pragmas, and added a basic README.

Add a webpack plugin that:
- Scans module sources for the ssr-ready pragma
- Scans non-npm dependencies of these modules, and checks that they also have
  the ssr-ready pragma. Adds a webpack compilation error if not.
- Bails the process if errors are found(!)
@ehg ehg force-pushed the add/webpack-ssr-checker branch from 85e21a8 to 9a25324 Compare January 11, 2016 14:00
@seear
Copy link
Contributor

seear commented Jan 11, 2016

Readme looks fine, good to merge 👍

ehg added a commit that referenced this pull request Jan 11, 2016
Build: Add pragma check webpack plugin for server side rendering
@ehg ehg merged commit 354cd5c into master Jan 11, 2016
@ehg ehg deleted the add/webpack-ssr-checker branch January 11, 2016 14:12
@ehg ehg removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Jan 11, 2016
ehg added a commit to Automattic/gridicons that referenced this pull request Jan 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants