Suppress the warning in reproducible environment

[RaitoBezarius]

Hi there, thank you for this awesome ecosystem of packages.

I am a developer in the NixOS ecosystem where we package a lot of Node.js-based projects and I encounter a lot in some build phase or install phase a warning of the form:

Why you should do it regularly:
https://github.com/browserslist/browserslist#browsers-data-updating
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db

I think it is relevant, but I wonder if there is a way to have an environment variable to prevent them from appearing as in a highly reproducible environment, it is too late to worry about update or not, all dependencies are pinned and most of the time, we are in an offline environment without network access. Having such a thing would greatly improve the quality of build logs and make it easier to read for users and maintainers.

What do you think?

[ai]

What Browserslist config do you have?

[RaitoBezarius]

What Browserslist config do you have?

Well, I hit this on https://github.com/knadh/listmonk/tree/master/frontend codebase, but I happened to get these errors on many Node.js projects, getting the complete list is quite hard (>100 projects).

[ai]

> 1%
last 2 versions
not dead

This Browserslist config is not “a highly reproducible environment”. It has a lot of time sensitive queries. For instance, last 2 versions changes every month or so.

[RaitoBezarius]

Right -- but there is no lockfile for Browserslist config, is there?

I mean, when we do package software, we rarely have the choice to track all Browserslist config and replace them with pinned versions, we rely on the data provided in the project's lockfiles, and we download it once, then archive it, and replay it once the software is actually installed / built, etc.

[ai]

but there is no lockfile for Browserslist config, is there?

The whole idea of Browserslist is to have rolling releases. Not lock versions since it is very bad for web performance.

But there is an idea:

1. Add to Browserslist a mark to time-sensitive queries
2. Do not show a warning if config didn’t use any time-sensitive queries
3. Next you will be able to change your config to something like chrome >= 100, firefox >= 100

I personally think that it is a bad idea and better to have a CI to update npm lock file.

[RaitoBezarius]

but there is no lockfile for Browserslist config, is there?

The whole idea of Browserslist is to have rolling releases. Not lock versions since it is very bad for web performance.

But there is an idea:

1. Add to Browserslist a mark to time-sensitive queries
2. Do not show a warning if config didn’t use any time-sensitive queries
3. Next you will be able to change your config to something like chrome >= 100, firefox >= 100

I personally think that it is a bad idea and better to have a CI to update npm lock file.

Hmm, I think it makes sense for upstream developers of a project, but for Linux distribution maintainers, I do not see how it solves the issue, Browserslist would still want to get an update and access network, right?

But, the whole thing about Nix builds is they are sandboxed and cut off from network access.

We can gently ping upstream developers and try to ask for better usage of Browserslist config but there is a lot of software out there which is not complying with these best guidelines and we are out of luck for this scenario, right?

[ai]

I do not see how it solves the issue, Browserslist would still want to get an update and access network, right?

You need to update caniuse-lite only every 5 month. Anyway, we have a security updates, it is not a problem to do it.

But, the whole thing about Nix builds is they are sandboxed and cut off from network access.

If you are installing a OS without security updates for 5+ month, I have a big question for this process.

Still, if you are sure about your use case, we can add this idea (of printing a warning only on time-sensitive queries in the config) to Browserslist. But you will need to help me with a PR.

[RaitoBezarius]

I do not see how it solves the issue, Browserslist would still want to get an update and access network, right?

You need to update caniuse-lite only every 5 month. Anyway, we have a security updates, it is not a problem to do it.

Yes, but we do need to update it in the project, right? If that's a solution, we can take it.

But, the whole thing about Nix builds is they are sandboxed and cut off from network access.

If you are installing a OS without security updates for 5+ month, I have a big question for this process.

I think I never said this -- Nix builds are sandboxed, it does not mean that there are no security updates ; but you do understand that the major part of the Node.js ecosystem who actually deploy stuff do not do security updates because this information is lost when they build a Docker image or whatever and there are tons of applications running out there without any security updates on the Node.js packages due to the insane package granularity.

Security updates in Node.js final projects are complicated due to this, but there is only so much we can do because of the size.

Still, if you are sure about your use case, we can add this idea (of printing a warning only on time-sensitive queries in the config) to Browserslist. But you will need to help me with a PR.

No problem for doing the PR, I am still uncertain if it is going to solve a significant part of the logs we are getting in our sandboxed builds, so I think it is better to have a way to ignore the need of updating caniuse-lite.

Otherwise, maybe the real solution is that we override/patch all upstream projects in our Nix package repositories to use a force-updated version of caniuse-lite (the latest one out), would that work or is there any concern for breaking changes or something? Because we do not have npm update or fancy tooling alas to perform version constraint resolution at this time. I am just worrying this is much, much more complicated to actually do (but this is a valid concern).

[ai]

Otherwise, maybe the real solution is that we override/patch all upstream projects in our Nix package repositories to use a force-updated version of caniuse-lite (the latest one out), would that work or is there any concern for breaking changes or something?

I, personally, think that if you write last 2 versions in config, you expect target browser changes on every browser release. It was you explicitly asked. So I don’t think that last 2 versions update is breaking changes.

I must warn you about possible bugs in caniuse-lite releases. We had only one-two bugs in recent 5 years (the package contains simple JSONs, but Can I Use database structure is fragile). But with a simple 1 week delay you will be pretty safe (all bugs were found in a 30 minutes and fixed in 1-2 days).

[ai]

BTW, Browserslist was created as a tool for developers and I never thought about distribution in common package managers like apt or Nix. The idea is that it should be a specific tool for people who know what are they doing and using latest versions.

[RaitoBezarius]

I, personally, think that if you write last 2 versions in config, you expect target browser changes on every browser release. It was you explicitly asked. So I don’t think that last 2 versions update is breaking changes.

Yeah, discussing it with you made me reconsider the idea of this whole issue (we can close it, by the way, I think).

The best way forward is to collect & measure the actual number of projects using "last"-form constraints and see how up-to-date they are and what can we do to update caniuse-lite directly at the packaging site.

BTW, Browserslist was created as a tool for developers and I never thought about distribution in common package managers like apt or Nix. The idea is that it should be a specific tool for people who know what are they doing and using latest versions.

Of course, but nowadays, Browserslist is included in many JavaScript/TypeScript bundlers tooling which becomes a dependency for frontend projects, when distribution like NixOS provide the frontend package build recipe, we need to package the whole tree of dependencies to reproduce the npm run build command which, in turn, do some calls to autoprefixr/whatever is the norm now, and I guess interacts with Browserslist and here we are now :).

So I do get that it is a specific tool (and I use it that way myself) but it seems like it has overgrown into an industry-standard tool which is systematically applied at each build, which works fine when you do things with network access, but makes it harder for certain class of users (like myself).