enable local css source maps with flag #9415
Conversation
There was a problem hiding this comment.
LGTM, although I wonder if there's a setting or different type of source map that could help free up some memory. It might be worth experimenting with this line sometime and see if it makes any difference.
Sometime, I wonder if we could implement a help command or something as a way of documenting these args. This seems like one that feels natural as just as an extra arg passed to the regular watch task instead of a separate way of starting the site, but without it in the package.json it's hard to make it visible.
config/webpack.config.js
Outdated
| @@ -43,6 +43,10 @@ const configGenerator = (buildOptions, apps) => { | |||
| ENVIRONMENTS.VAGOVPROD, | |||
| ].includes(buildOptions.buildtype); | |||
|
|
|||
| const enableCSSSourcemaps = | |||
| buildOptions.buildtype !== ENVIRONMENTS.LOCALHOST || | |||
| buildOptions['local-css-sourcemaps']; | |||
There was a problem hiding this comment.
If buildOptions['entry'] is passed, should it flip to true? Just thinking that if we've limited what apps we're compiling, then maybe it should consider CSS sourcemaps to be safe too.
| @@ -24,7 +24,8 @@ very secret. | |||
| | build the production site (dev features disabled). | `npm run build -- --buildtype vagovprod` Note the extra `--` is required otherwise npm eats the buildtype argument instead of passing it on. | | |||
| | build the site with optimizitons (minification, chunking etc) on. | Set `NODE_ENV=production` before running build. | | |||
| | reset local environment (clean out node modules and runs npm install) | `npm run reset:env` | | |||
| | run the site for local development with automatic rebuilding of Javascript and sass | `npm run watch` then visit `http://localhost:3001/`. You may also set `buildtype` and `NODE_ENV` though setting `NODE_ENV` to production will make incremental builds slow. | | |||
| | run the site for local development with automatic rebuilding of Javascript and sass without css sourcemaps | `npm run watch` then visit `http://localhost:3001/`. You may also set `buildtype` and `NODE_ENV` though setting `NODE_ENV` to production will make incremental builds slow. | | |||
| | run the site for local development with automatic rebuilding of Javascript and sass with css sourcemaps| `npm run watch:css-sourcemaps` then visit `http://localhost:3001/`. You may also set `buildtype` and `NODE_ENV` though setting `NODE_ENV` to production will make incremental builds slow. | | |||
There was a problem hiding this comment.
It might be worth adding a note about the CSS source maps being heavy on memory and that's why we separate them out.
|
Thanks- I'll take a look at this line @ncksllvn. It doesn't look like we're using this plugin in the local build ( I'm not familiar with the difference between plugins and loaders and if they're mutually exclusive (e.g we would use this in place of css-loader sourcemaps). |
…ts-website into build/16380-make-dev-css-sourcemaps-optional
va-bot
temporarily deployed
to
master/build/16380-make-dev-css-sourcemaps-optional
Description
This is an attempt to prevent the
npm watchtask from crashing after multiple re-builds are triggered. The issue was tracked down tocss-loaderhaving source maps on by default. Memory profiles suggest that webpack or the css-loader is retaining old build's strings in memory.I believe this is the core issue and will revisit adding css source maps to the default watch task when it's resolved.
This change turns off css sourcemaps by default for local development. A new script has been added that
The new script will probably still crash after node runs out of memory but this will give it more room to fail and limit that failure to work that requires debugging css with sourcemaps.
Testing done
npm run watch:css-sourcemapsafter 20+ rebuilds:npm run watchafter 20+ rebuilds:Screenshots
Acceptance criteria
Definition of done