Developing with Yarn & Webpack, issues with error reporting and css

I’m new to Sage and coming from JointsWp which uses grunt. I’m having a couple of issues working with yarn start.

  1. When it fails there’s no report. In order to see what broke it seems necessary to quit and run yarn run lint:styles to get the details, return to editing the scss, and repeatedly run yarn run lint:styles` again to see if the problem is solved. Surely there’s a better workflow that I am missing? Some way to turn on error reporting?

  2. When working under yarn start there are no stylesheets — everything is rendered through webpack delivering the scss. This means there’s no way to see the rendered css and no way to make easy edits in the Inspector. It’s necessary to return to editing the scss, triggering another build, and return to the browser to see the results.

  3. Doing step 2 is sloooow. I’m used to grunt where a scss edit is rendered in milliseconds. With yarn start it takes many seconds to rebuild all styles and scripts each time. For any single scss edit in Sage 9, with grunt I could have made 3-4 changes in the css in the Inspector and seen the results before settling on an edit to be made to the scss.

FYI each of the above issues cost me hours of research. I thought the webpack’s erasure of the css was a bug until I went to report it here and found a half-dozen identical reports. A note in the Sage 9 documentation would be appreciated.

Advice welcome.

Are the values in your config for your local dev URL or the path to your theme directory correct? What version of Sage 9 are you using?

publicPath would be /wp-content/themes/theme-name if you aren’t using Bedrock.


  1. The error shows up right on the page as well as in the console and the terminal:

  2. This means there’s no way to see the rendered css and no way to make easy edits in the Inspector. It’s necessary to return to editing the scss, triggering another build, and return to the browser to see the results.

    What does this mean?

  3. Probably related to 1 & 2?

Thanks for the quick reply!

I’m using Sage 9 beta 4 with Foundation.

devURL is correct, I’ve been pretty good about following the documentation.

  "publicPath": "/wp-content/themes/rc3-theme",
  "devUrl": "http://raaup.test",
  1. I only received the word “ERROR” in red in terminal and nothing on the webpage itself. But today when I tried to reproduce that I am getting full error reporting as in your example. Last night when I googled the issue I found numerous other reports of no error reporting, but I can’t reproduce it yet. The best I could do today is refer to those other reports I found. =(

  2. & 3. I’ll get back to in a couple of hours.

#1 may be caused by the issue resolved in this PR: https://github.com/roots/sage/pull/1961

#2 Editing in Inspector/Developer tools.

In my workflow I’m often inspecting an element, viewing the html and css, and making small experimental changes right in the developer tools window. I can see the rendered css and how it affects elements. Here’s a screen cap showing editing p.margin-bottom:

51 AM

With webpack that’s not an option. The developer tools window doesn’t show the css, it shows the individual scss files and their effects on the element. Main.css is empty, and the sources pane show scss files pulled from dozens of locations. There’s no way to use the developer tools to make experimental edits to the css or look at the rendered css to see what the scss is outputting:

56 AM

#3 I prefer this method of experimentation because the results are instant. If I am playing with margins I can rapidly try 1rem, 1.5rem, 1.25rem, etc, to find the measure that works best, then return to Atom to enter that number into the scss for render. With webpack each individual change takes 3.4 seconds to compile and another n seconds to reload the page (2015 MacBook Pro 16GB RAM). Rapid experimentation doesn’t seem possible.

Is there something I’m not understanding about best development practices here?

For #2, what you’re seeing in the browser is the CSS sourcemaps and they’re just an additional tool to make your development life easier, particularly when using a pre-processor and you often have your CSS split across multiple files. You can even set up Chrome to write your inspector changes directly to those source SCSS files but I digress…

I’m not sure what you think is happening with the CSS but it still should be rendered and be overridable via the inspector - your 2nd screenshot shows the kind of thing I see and I am easily able to change the values in the inspector and see the results instantly. What happens when you try editing the values? You need to be sure that there isn’t some other CSS that is overriding the change you are making in the inspector.

Of course, you can disable sourcemaps in resources/assets/build/config.js but I don’t think that is the cause of your problem.

#3 - why aren’t you running yarn start and using the watcher? It’s always going to be slower if you do a full build, plus you have to manually trigger it each time. If you use the watcher, it will only recompile what it needs and it should be considerably faster - back in the milliseconds.

It can take a while to get used to this workflow but it’s well worth it :slight_smile:

3 Likes

My bad. I meant yarn start not yarn run build. I am unfamiliar with yarn and got the names confused, but it’s yarn start that I was running. I’ve edited the original post to reflect that.

Though the documentation does say to use yarn run build which is what I started with.

For #2 I’m simply more familiar with debugging/experimenting in the css. When editing css you are editing the final value. When editing scss you are editing one of many possible inputs to the final value.

Though the idea of the inspect sending changes to the scss is intriguing… Is that a plugin?

In yarn start the css is not rendered and visible.

I looked in resources/assets/build/config.js but have no idea what it means. I don’t think I have the time this month to learn whatever it is. =)

#3 I am using yarn start which is a lot like grunt watch and it is how I prefer to edit scss. My only gripe is not having the rendered css in the inspect, something that grunt offers and yarn doesn’t (until I learn how to edit the config).

I think there’s some crossed wires here as you will definitely see the CSS in Chrome’s inspector for example. You can also change these values as you are describing:

css-edit

As @Stephen said, it’ll show you the .scss file that the rules are being defined in (sourcemaps) but it’s just CSS values to change. For example, in the above video, you can see the there are various vendor prefixes for CSS rules. These are only added after the .scss are compiled down to CSS.

EDIT: OK, the video is pretty hard to see at that size but try: https://discourse.roots.io/uploads/default/original/2X/3/3fa3af12cde6893e63f3f9db466ed1234f3e8ae0.gif

1 Like

@slam I see your confusion and there’s so much to take in at first (I can relate, I’m still figuring out a lot myself!) but it seems that there are some key things you haven’t yet grasped.

For starters, yarn is closely related to NPM (think of it as an improved version). Yarn/NPM both have the ability to do a lot of things but their main purpose is as package managers - helping deal with all the little packages/libraries that are pieced together to make a bigger program. They will handle downloading the correct versions you need, plus any dependencies each package has - it’s very common for packages to rely on multiple other packages and on and on…

The important point is that Yarn/NPM aren’t directly comparable to Grunt or Gulp but they can do some similar things, like run commands. For example when you do yarn run start (or yarn start for short), you are using Yarn’s script runner and it looks inside the package.json for the scripts section.

If you check out the Sage package.json, you’ll see it happens to have a script named start that actually runs webpack --hide-modules --watch --config resources/assets/build/webpack.config.js - this is what is doing all the work to process the SASS files, create sourcemaps, convert JS, optimise images, run linters etc. There’s a ton of stuff going on and I won’t pretend I understand even half of it but it’s good to have at least a high-level understanding. Sage is awesome because you don’t have to be a webpack master to benefit from all this functionality.

I don’t really understand what you mean by this but I can only assume that you’re confused by the sourcemaps - I’d suggest you do some background reading on them but in summary, they just provide pointers from the compiled CSS to their original locations. The CSS is still being processed (if it wasn’t you would be getting an unstyled page). Look at @nathobson’s excellent screen capture above - that’s what you should be seeing when you change values. As I asked earlier, what happens when you try changing the values in the inspector? I’d be surprised if it didn’t work as normal…

If you want to have the changes in the inspector saved to your source files, you need to use a feature of Chrome DevTools called Workspaces. Here’s some information about it:

https://developers.google.com/web/tools/setup/setup-workflow

However, I wouldn’t recommend trying to do this until you get more comfortable with the standard setup.

Good luck!

1 Like

Another possibility is that yarn build:production was run. If yarn build:production is run, you’ll need to run yarn build at least once before running yarn start again to clear out the versioned, cache-busting files and begin developing again. This catches me off guard about once every three weeks.

yarn start also runs its own little web server at localhost:3000 where you’ll see the live changes to your site. Are you able to reach that address while yarn:start is running?

1 Like

This is a very good point.

Can you post a screenshot of what you are seeing in the inspector?

There’s a screenshot of the inspector here already and it seems to show that everything is normal and it’s not in production mode (otherwise there wouldn’t be sourcemaps, right?).

Good tip about build:production @MWDelaney but I don’t think that’s it in this case - at least from what I’ve seen so far…

Yup, ignore me :nerd_face:.

20 chars

Thanks for the great help!

Yes, I am able to see the site at localhost:3000 and that’s where my screencaps are from.

If I am following y’all, the scss is rendered into css, even if the inspect shows the source scss files and not the final main.css output file. Is this what you mean by “sourcemaps?”

I also now understand that it’s not yarn doing this, but webpack. It also looks like I could write another webpack config that only watches scss and doesn’t rebuild the js, too, for when i am working only in scss (unless by default webpack behavior is to only re-process the thing that was changed (styles, say) even though it watches both).

That brings up some questions I could answer with experiments but maybe I ought to ask them here anyway. Like, if two scss files modify the same element (say one assigns a color and the other modifies it with a mixin) how will that appear in the inspector?

Ok, so I read this: https://www.sitepoint.com/using-source-maps-debug-sass-chrome/

And now I grasp sourcemaps. This is a whole new concept to me! I can see how it would be useful.

The CSS rules that appear in the inspector are the rules as the browser has interpreted them. If both your CSS files touch that element through the same class, then both those rules should appear under one class (I think). It will depend on how your build process assembled the CSS from your SCSS. The point is that the CSS shown in the inspector reflects how the browser is interpreting your styles, not necessarily how those styles are laid out “physically”, if that makes sense.

Thanks Ben,

“The point is that the CSS shown in the inspector reflects how the browser is interpreting your styles, not necessarily how those styles are laid out “physically”, if that makes sense.”

It doesn’t exactly make sense yet, but… my old grunt way of doing things meant troubleshooting the processed .css file and then figuring out how the various scss files were generating that css. This meant I was holding a kind of mental “process map” in my head that described how the scss becomes css.

With sourcemaps it looks like some of that mapping is now externalized out of my head and into the inspector. The overall process is the same — use the inspector to find out where in my scss I need to make changes — but the in-between steps have been altered somewhat.

Does that sound right?

Yes, I think so.

You can actually see this in action right here on the Roots Discourse, if you open up the Inspector. Just click on the filename next to a class definition, and it’ll take you to the SCSS file being used to render it. Here’s a quick video of me doing that: http://recordit.co/UbP3jraHjX

1 Like

yarn start does exactly this. It only re-compiles and refreshes the stuff you changed. yarn build recompiles everything.

3 Likes