@ai It is not possible to upgrade indirect dependencies, as explained here.

There are two really bad alternative solutions here:

• Either manually modify yarn.lock. This comment explains why that is a terrible idea.
• Install it as a direct dependency. But that significantly increases the potential for diamond dependency conflicts.

Can you PLEASE add a way to just update the database file without having to mess with dependencies?

FYI: You might wonder why is this so important to us – Having to sift through literally dozens of these pointless warning messages when working in certain CLI environments is really quite troublesome. It is causing quite the headache.

It is not possible to upgrade indirect dependencies, as explained here.

This issue is about updating the single indirect dependency.

yarn upgrade works. It is just update all dependencies.

If you do not want to update all dependencies, you need to change yarn.lock file. You do not need to do it manually. There are many tools to do it.

literally dozens of these pointless warning messages

They are not pointless. Having old caniue-lite slow down your JS bundle a lot by adding unnecessary polyfills.

The developer’s attitude here is very disappointing; it’s patronizingly paternalistic to tell people that they can’t be trusted to build software in a certain manner and you need to save them from themselves and in the process heroically save the web itself.

…and weirder still he himself added a silence option back in 2019. I tracked it down manually and I’m just sharing it here. In the node.js file:

  oldDataWarning: function oldDataWarning (agentsObj) {
    if (dataTimeChecked) return
    dataTimeChecked = true
    if (process.env.BROWSERSLIST_IGNORE_OLD_DATA) return

    var latest = latestReleaseTime(agentsObj)
    var halfYearAgo = Date.now() - TIME_TO_UPDATE_CANIUSE

    if (latest !== 0 && latest < halfYearAgo) {
      console.warn(
        'Browserslist: caniuse-lite is outdated. Please run:\n' +
        'npx browserslist@latest --update-db\n' +
        '\n' +
        'Why you should do it regularly:\n' +
        'https://github.com/browserslist/browserslist#browsers-data-updating'
      )
    }

Therefore you can set a property in your environment variables (process.env) which will silence the warning:

process.env['BROWSERSLIST_IGNORE_OLD_DATA'] = true;

(or whichever method is relevant to your project, e.g. the dotenv pattern etc)

At the very least this warning should provide some guidance on how to perform the upgrade when this is a nested dependency, as it will be probably most of the time, since it’s used by Babel (and thereby most React devs)

Hiding this warning will not solve the core of the problem that your build tool could be slowed down by many unnecessary polyfills.

You need to fix the source of the problem, not blaming a people who tell you about the problem.

@ai I think this message is too aggressive. I am seeing it in a node project, when running eslint, with no babel config at all. I don’t have caniuse-lite, browserslist, or even babel as a dependency. Am I really supposed to add babel and a config specifying that this a node target just get this warning, which is totally irrelevant to my project, to go away??

I don’t have caniuse-lite, browserslist, or even babel as a dependency.

Call npm ls to see who use browserslist.

The problem is not a warning, but too big complexity of some tools, which wasn’t configured correctly because of many reasons.

@mmkal the problem is that with wrong setup we can’t detect that project care about browsers or now.

!!packageJson.browserslist will not work. Many web apps (which care about browsers) are using default Browserslist and do not have packageJson.browserslist.

When you say “your build tool”, do you mean eslint? babel? babel’s default config?

I am not sure. To detect who called Browserslist in Node’s project, I need to spend a time for investigation.

It will be better if you will do this research because it will not put all work on me.

@Domiii

I would suggest that the warning could at least link to a complete website dedicated to all the different problems covered by your (may I say: very crude?) detection mechanism, that goes way more in depth on this issue.

It is an excellent idea. But it requires too much time, which I do not have. It is a problem with Browserslist funding.

least allow for a silencing option

This option will be used by user with real problem of unnecessary polyfills. I’m afraid that adding this option will slow down the Internet because more webapps will have bigger JS bundles.

maybe it should not warn so aggressively

What do you suggest here? Note that we still should be visible for webapps developers since outdated caniuse-lite is a big problem of webapps performance.

For those wanting a more targeted upgrade with npm:

npm --depth 20 update --save caniuse-lite browserslist 

--depth is deprecated and will throw a warning, however the command worked for me and only updated a few packages instead of a full npm update.

yarn upgrade resolved for me

Could be a big or a rare environment edge case.

Just call npm update instead.

probably because I don’t have a direct dependency on caniuse-lite either

You do not need caniuse-lite in direct dependencies. We are using our own script to update all nested copies of canisel-lite in your dependencies tree.

Not sure if you can fix this?

You can use any other way to update node_modules dependencies. For instance, you can run npm update.

npx browserslist@latest --update-db is just a script for 95% use cases. You do not need to use it. You need to keep caniuse-lite fresh.

The problem is not a warning, but too big complexity of some tools, which wasn’t configured correctly because of many reasons.

The Problem

I would argue that, JavaScript tools and toolchains in 2022 are complex in general.

If the problem is that a node project has non-node targets (or, similar to my case, not configured target at all or otherwise incorrectly), the warning should reflect that the target is wrong, and not just assume that an outdated browserslist version causes trouble.

This means that the warning (as it is right now) is incorrect: The problem is not that browserslist is out of date, but that the target was configured incorrectly.

Possible Solutions?

In general, I would suggest that if you take it upon yourself to aggressively warn about problems that are often times introduced by third-party providers, you might want to provide a proper way to deal with it, not just make a single one-shoe-fits-all suggestion that does not work half of the time.

What could be done:

• I would suggest that the warning could at least link to a complete website dedicated to all the different problems covered by your (may I say: very crude?) detection mechanism, that goes way more in depth on this issue.
• If you don’t want to (or don’t have the resources to) improve upon your warning mechanism, maybe it should not warn so aggressively, or at least allow for a silencing option…?

@ai I’m sorry if I gave the impression I was blaming any particular people. The problem, to me, is that browserslist - the tool, not the people behind it - is incorrectly assuming that a node project is cares about browsers. It’s possible that it’s being confused by a default babel configuration in eslint, maybe? But the warning message is devoid of context so it’s hard to say. I don’t think it’s right for a library that is typically so deep in dependency trees to confidently say “there’s a problem in your setup”. The only real problem, as far as some users are concerned, is that an irrelevant message is being printed out to stderr. Performance is fine, functionality is fine.

Note: in my case, this is in a rush project, and npm ls doesn’t work. I’m not sure When you say “your build tool”, do you mean eslint? babel? babel’s default config? Seems really strange to require users who aren’t explicitly using babel to have to debug this. I agree that overly-complex dev dependencies are a general issue. I disagree that browserslist should be talking about it by saying “caniuse-lite is outdated”.

I don’t want to be unconstructive though: what if browserslist did something like:

const packageJson = require(process.cwd() + '/package.json')
const projectCaresAboutBrowserslist = !!packageJson.browserslist

if (!projectCaresAboutBrowserslist) return

before printing the message?

yarn upgrade in this case.

You do not need to have direct updates. yarn upgrade should update indirect versions too.

@ai I’m using yarn, not npm.

And what library should I update? I don’t have a direct dependency on neither browserslist nor caniuse 😕

@ai The problem is that the --update-db command does not do anything. That’s a bug, no?

It says:

Latest version:     1.0.30001286
Installed version:  none

And once it finishes, it did not change anything, and the warnings remain.

Not sure what to make of that.

npx update-browserslist-db@latest

use this instead of recommended

Hi, I am also struggling with warnings due to Browserslist:caniuse-lite is outdated. Please run:npx browserslist@latest --update-db

I still disagree with this heavy-handed approach, but I also do understand why you feel so strongly about it.

On the plus side, I finally found out why this warning is so egregious to me: I got the warning even when using node (no browser involved), which was the most frustrating aspect of this.

Problem: When targeting node, the warning still appears.

Workaround: targets: ...node... must be explicitely added to babel options (not just @babel/preset-env).

babel.config.js:

const targets = {
  node: 16
};

module.exports = {
  targets,   // <- this prevents `browserslist` warnings
  presets: [
    [
      '@babel/preset-env',
      {
        targets,
        // ...
      }
    ]
  ]
  // ...
};