As of https://github.com/webpack/webpack/pull/4381 webpack will (once released) allow to suppress warnings as requested here: https://github.com/webpack/webpack/issues/4263 .
Happy to help out with a PR, if you can specify what is wanted, wanted to be suppressed
followup from #1924 @Timer
Perfect, we'll try to take a look at this soon, probably after the 0.10 release which should be by the end of the month.
We'll have to work out the details and wait on the webpack release anyway. 😄
man I need this! localForage gives the prebuilt file warning, so in CI it breaks. :(
is there any workaround to this ATM?
@kellyrmilligan This hack: CI=false yarn build (not sure what other implications setting CI to false has though)
@FredrikNoren This doesn't work for me... Do you have an idea why?
@levrik
What warnings exactly are you trying to suppress? The ones in this issue don’t seem to fire with latest versions.
@gaearon I want to suppress some linting warnings that are preventing the production deployment or... I don't really want to suppress them. I only want that they don't block the deployment.
@FredrikNoren @gaearon Ok
unset CI
yarn build
CI=true
did the trick. Seems like it's only checking for the existence of the CI variable and not for the content.
Would be nice to suppress warnings like "warning 'variable' is assigned a value but never used no-unused-vars". I usually just duplicate a template folder to create a new component and they import things that haven't been used yet, so I get this warning a lot.
@MiLeung
/* eslint-disable no-unused-vars*/
at the top of your files
should give you what you want
@MiLeung This warning is valuable for catching some very annoying mistakes though.
@gaearon Probably, but I don't think importing something or making a new variable would cause anything to break; at least not in my current project.
It’s sometimes a sign of a mistake in logic. For example if you read some parameter but forget to use it. So it might not “break” things but might indicate that the code doesn’t do what you think it does. As for imports, it is valuable for catching unused imports that bloat the bundle. For example if you import a whole library in the main bundle but it’s only necessary in code split chunks.
I support this issue, it is especially relevant when getting warnings caused by other dependencies way down the dependency-tree. We can't find a way to get around this warning:
./~/ajv/lib/async.js
96:20-33 Critical dependency: the request of a dependency is an expression
./~/ajv/lib/async.js
119:15-28 Critical dependency: the request of a dependency is an expression
./~/ajv/lib/compile/index.js
13:21-34 Critical dependency: the request of a dependency is an expression
(the specific warning type is discussed in other issues, this was just to give an example that would support the issue of suppressing warnings).
So https://github.com/facebookincubator/create-react-app/issues/1947#issuecomment-304072915 was a life safer for us.
I know webpack has added a warning filter to their config but this does not solve our problem when getting warnings from other dependencies and not having access to configuration. Any solutions ?
React's deprecation warnings after an upgrade cause Capybara PhantomJS to fail builds on CI. My temporary workaround was settings js_errors: false. Terrible bandaid, but now warnings aren't blocking deploys.
Now obviously the next step is to set js_errors: true and hunt down and fix every single warning. Fun
Below solves the warning.
const packageJson = require('./package.json');
module.exports = {
externals: Object.keys(packageJson.dependencies)
.reduce((externals, pkg) => {
externals[ pkg ] = `require("${pkg}")`;
return externals;
}, {}),
};
@isbdnt This doesn't solve anything for CRA users and is not relevant to this repository.
@TSMMark This issue is about build-time warnings and has nothing to do with React (runtime) warnings.
Going to close this as stale. Please raise a new issue with more details if you're interested in this.
Most helpful comment
Perfect, we'll try to take a look at this soon, probably after the 0.10 release which should be by the end of the month.
We'll have to work out the details and wait on the webpack release anyway. 😄