Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Headless ? #4

Open
cyrilchapon opened this issue Mar 27, 2018 · 7 comments
Open

Headless ? #4

cyrilchapon opened this issue Mar 27, 2018 · 7 comments
Labels
feature request Interesting request under consideration

Comments

@cyrilchapon
Copy link

Is there a way to use, say, env variables to update the file in pure headless mode ?

This would allow hooking it in our CI pipeline, thus updating stats every push in the process

@dmfrancisco
Copy link
Member

Thanks for opening this issue 👍 The short answer is no.

This is something that I also need and I'm planning to do (but please feel free to send a PR if you end working on it!). I'm curious how you were planning on integrating with your CI. Any chance you could share your thoughts?

In many CI services you have access to the git history and so with support for headless mode you could run browserslist-ga and commit back the changes (if those changes were relevant enough) to your version control (similarly to what greenkeeper-lockfile does). Is this the kind of setup you were thinking of, or is your intent to skip adding browserslist-stats.json to your version control and have it compiled upon deliver?

@dmfrancisco dmfrancisco added the feature request Interesting request under consideration label Mar 27, 2018
@cyrilchapon
Copy link
Author

cyrilchapon commented Mar 27, 2018

I'm curious how you were planning on integrating with your CI. Any chance you could share your thoughts?

In many CI services you have access to the git history and so with support for headless mode you could run browserslist-ga and commit back the changes

Well I'd go with a KISS approach, gitignore browserslist-stats.json and run

package.json

{
  [...],
  "scripts": {
    "build": "browserlist-ga && [WHATEVER BUILD CMD]"
  }
  [...]
}

😄

(Along with a git pushed .browserslistrc)

@dmfrancisco
Copy link
Member

That makes sense, thanks for sharing 👍 I believe there are some benefits in having this file under version control, but on the other hand as you mentioned there's the risk that the setup becomes too complicated. But either way being able to run browserslist-ga in non-interactive mode is necessary and so it's something I want to work on soon. I'll report back once I have more news!

@cyrilchapon
Copy link
Author

cyrilchapon commented Mar 28, 2018 via email

@dmfrancisco
Copy link
Member

I agree 👍 One nitpick regarding babel-preset-env and other tools that use Browserslist, is that those queries (like > 1%) actually run against a static file inside the caniuse-lite dependency. So if you have a yarn.lock or package-lock.json in your project, it should use the same data across builds.

@connorjclark
Copy link

I am leaning towards not wanting a headless mode. I am thinking of a case where GA stops reporting data (For whatever reason), this goes unnoticed, and the generated browserslist is missing tons of browsers that very-much ought to be under support. I think having this tool be manually run and audited is important.

@dmfrancisco
Copy link
Member

Interesting feedback, thank you 👍

A month ago I started a prototype of a bot using GitHub Apps and a new permission that gives you write and read access to a single file in the repository the owner allows. I haven't worked on it since, but in case anyone is interested here's what I have so far: https://github.com/dmfrancisco/browserslist-ga-bot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Interesting request under consideration
Projects
None yet
Development

No branches or pull requests

3 participants