No default browserslist config causes obscure develop and build fails

[narration-sd]

Description

Even a fresh gatsby-starter-hello-world site fails on gatsby develop, with webpack errors and no clue it's because of a missing browserslist. In fact, the message sends you to a debug-html page with no idea about this either. gatsby build does give a browserlist message, but it doesn't say the truth, that there's no configuration.

Gatsby promises to provide a default configuration, but never does since many months previous. Once you know, of course you can fix this, but it's not what a fresh Gatsby developer needs to meet on a first try, especially, is it?

Steps to reproduce

1. Create a default project, using: gatsby new gstarter https://github.com/gatsbyjs/gatsby-starter-hello-world
2. run gatsby develop

Expected result

Develop should happen and server start with demo project showing.

Actual result

Develop compile failed, with spurious error messages and no clue there or in offered links what the real problem is. Below is what it looks like. A build, by comparison, does give a line mentioning browserslist, but only as a failed shell command -- no clue why unless you know. In any case, Gatsby promises to give a default browserslist, but does not: this is the real issue.

The develop run and fail:

$ npm run develop

> gatsby-starter-hello-world@0.1.0 develop C:\vagrant\release\gstarter
> gatsby develop

success open and validate gatsby-configs - 0.016 s
success load plugins - 0.048 s
success onPreInit - 0.006 s
success initialize cache - 0.010 s
success copy gatsby files - 0.460 s
success onPreBootstrap - 0.017 s
success source and transform nodes - 0.017 s
success building schema - 0.148 s
success createPages - 0.002 s
success createPagesStatefully - 0.061 s
success onPreExtractQueries - 0.002 s
success update schema - 0.023 s
success extract queries from components - 0.094 s
success write out requires - 0.013 s
success write out redirect data - 0.006 s
success onPostBootstrap - 0.002 s
⠀
info bootstrap finished - 9.361 s
⠀
success run static queries - 0.003 s
success run page queries - 0.032 s — 2/2 73.49 queries/second
error There was an error compiling the html.js component for the development server.

See our docs page on debugging HTML builds for help https://gatsby.dev/debug-html


  WebpackError: ./.cache/develop-static-entry.js








  - bootstrap:8
    lib/webpack/bootstrap:8:1


  - bootstrap:22 cachedFunction
    lib/webpack/bootstrap:22:1


  - bootstrap:66 config.presets.reduce
    lib/webpack/bootstrap:66:1


  - bootstrap:63 recurseDescriptors
    lib/webpack/bootstrap:63:1

  - bootstrap:83 recurseDescriptors
    lib/webpack/bootstrap:83:1




npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! gatsby-starter-hello-world@0.1.0 develop: `gatsby develop`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the gatsby-starter-hello-world@0.1.0 develop script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\narrationsd\AppData\Roaming\npm-cache\_logs\2019-06-14T19_22_19_755Z-debug.log

narrationsd@DESKTOP-NU62DHV MINGW64 /c/vagrant/release/gstarter (master)

Environment

Run gatsby info --clipboard in your project directory and paste the output here.

  System:
    OS: Windows 10
    CPU: (8) x64 Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
  Binaries:
    Yarn: 1.16.0 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Python: 2.7.15 - /c/Python27/python
  Browsers:
    Edge: 44.18362.1.0
  npmPackages:
    gatsby: ^2.9.4 => 2.9.4 

[marcysutton]

Hi there! There's one step missing from your repro steps, cd gstarter. I can see from your stack trace that you were in the correct directory, just wanted to point that out.

What node version are you using? I can't reproduce this on a Mac with Node 12, but it could either be a Node version thing or a Windows thing.

[narration-sd]

Hi Marcy,

$ node -v
v10.15.3
$ npm -v
6.4.1

These are on Windows 10 - always contemporary, and at present 1903, the fresh release.

I've kept to the non-futures standard versions as I'm preparing release of an actually live preview solution for SPAs on Craft CMS -- Gatsby first -- and wanted to be sure there weren't issues.

Interesting if somehow a standard version of Node could cause what's been unexpected here. I've just brought the problem up, though it's been happening consistently for months.

Or Windows?? This is all in js/React land, but anything's possible, isn't it - and there are some entertaining native build things happening for some of the included npm library parts which are part of Gatsby I think.

Anyway, if this isn't just a passing phase of Gatsby, maybe we can find something here...

Regards,
Clive

[narration-sd]

@marcysutton When you get back to this, I did a thing. I deinstalled node/npm, also gatsby-cli. Then I installed the very latest non-longterm node/npm, reinstalled gatsby-cli (-g), and made a brand new starter project. Engaging npm run dev on it gave the very same immediately errored result as before, telling me it had trouble with html.js, and referring to a debug builds page that won't help. There is again no mention anywhere of the real and simple problem, missing the promised default browserlist config.

The versions I have now are as follows, and I also tried running npm update then npm install in case there actually were uncompiled library components, but no.

$ node -v
v12.4.0

$ npm -v
6.9.0

I'd hoped this to be a solution, because you are confident it works on MacOs, and if so, to lose the impression I've had that Gatsby is in some ways a pretty loosely operated ship.

The reason I bother is not because I haven't been able to get along for months myself, but because the project is going out to persons many of whom will not be coding experts. They use packages. Enough of them use Windows. They will come back at me for advice, as my own package attracted them further to Gatsby, not because my provision fails with it. So I need to be able to post clear notes on what to do when it basically doesn't work, as I have seen in the manner of this issue report all along. So as not to be buried...

Thanks for what you and the team can come up with, and I think if this problem is as real as it appears to be, your Gatsby takeup will improve, when mere mortals can have it Just Work™️ as you intend, on Windows.

a p.s. is that the extra native code ability node 12 insists it needs installed is a nightmare -- running blind scripts which admit they could be dangerous, and take many minutes, making big logs and big installations. I really didn't want this on a machine I keep clean and up-to-date functional for developent. I realize it's not your problem at Gatsby, but better if this node 12 monster doesn't need to be used, just the LTS version instead, as nodejs itself recommends. So something to consider as far as this issue's solution...thanks again.

[KyleAMathews]

This error comes from the lack of a default browserlist config? Are you referring to another issue? Could you link to that.

[narration-sd]

@KyleAMathews Kyle, yes, missing browserlist config. It's not related to any other issue, except for that I mentioned the problem in the one you found.

So it's kind of a one-way link, and just used to explain why I was deleting the discussion there. Probably too completist, this time 🙈

I think the situation and problem are all pretty completely described, with fixup tries, above.

[narration-sd]

Late here, so had to make a correction on correction, in last message....better sign off....

[narration-sd]

@sidharthachatterjee Look, I'm not a novice posing a question.

It's a several-instances tested report, and a big problem up front especially shown by log, that there is no clue provided as to what's wrong.

So it doesn't deserve a slush pile label, do you agree??

[DSchau]

@narration-sd Sid added a label type: question or discussion which is very much accurate to the issue as it currently stands.

The error (as you've attempted to reproduce) is not reproducible for us so we can't confirm your error based on the info you've provided, therefore the label appears to be accurate.

However, this isn't to say that we don't care to fix your issue or help you, we just currently don't know how to help you because we can't reproduce it. Please try and presume good intent on our behalf, and we'll do the same for you.

Could you provide some more information as to what makes you assert this?

No default browserslist config causes obscure develop and build fails

We do provide a default browserslist config. Based on what you've provided, I'm not exactly sure what would lead you to conclude that it's a browserlist issue? Could you provide any more info?

[narration-sd]

Well, good to see where this is addressed in the source. However, I'm not seeing that it has the desired effect, on Windows 10 in the last months.

I puzzled why you think I didn't demonstrate, with the log posted above, but yes, that log doesn't mention browserslist. My intent was to show on the behalf of new Gatsby trying persons that when running npm run develop on a fresh gatsby new site, no relevant information for the failure is offered at all. The link to a fixups page has nothing relevant either.

If you choose then to run npm run build on the same fresh site, you will then get an error that does mention browserslist, very early so it may not be noticed for being scrolled off the page. But it is there, if not very informative.

If you then provide a browserslist config by any of the possible methods (in project.json, in .browserslistrc, etc.), then develop or build runs will be fine from then on.

These facts would seem to indicate missing browserslist config is the problem, I think?

To go further, just now I've wondered if sticking to npm (very latest now) on Win10 vs. yarn might be the problem. But no, npm is actually required for gatsby-cli, and the prevelance of yarn I found in doc to be actually only about developing on Gatsby itself. So that's out the window.

I've just re-installed gatsby-cli in the last hour so it will operate again, and tried once more a simple gatsby new sitename creation. As reported there I had also to add two extra libraries.

I then ran npm run develop, and got the same obscure errors. Adding a working .browserslistrc from another project, I was then successful using npm run develop. This has been the norm, as reported.

Now, I thought of one more thing. I usually do all these steps within PhpStorm, where I've also set gitbash as the default terminal shell. So, I try all this one more time, using a fresh and normative Windows cmd pane, and no IDE around it -- just plain.

• create site using gatsby new sitename works, of course cd into it
• npm run develop -- fails, on the current remains of issue fix(tutorials): rename "advanced" to "additional #14847, where I'll report next two steps apparently still needed
• npm install gatsby-plugin-sharp@reporter-npm
• npm install gatsby-source-filesystem@reporter-npm
• again npm run develop -- now passes reporter issues, but...gives the same no-info fail as reported.
• copy in working .browserslistrc
• npm run develop - now succeeds, and dev server runs

Conclusion: shells don't matter either. Only providing one's own browserslist config does. Automatic isn't there, somehow.

Your kind @marcysutton above suggested testing had been done using Macs. I would wonder if it has been done using Windows?

Just as backstop to all this, before I did any of the steps in this note, I did a npm cache clear --force, and the same -g in case that were necessary. So it was an entirely clean test, everything from npmjs fresh.

What would you suggest else I might try? And again, are you sure it's tested on Win10?

I thought of one more thing - tried webpack --version. Can't run that without webpack-cli, and checked that gatsby new sitename installed your own new-site-local-node_modules webpack, so that can't be it, right??

Thanks, Clive

[muescha]

You mean the browserlist mentioned here: Gatsbyjs Browser Support?

Can you give your browserlist config you added to fix the problem?

[muescha]

Maybe here is somewhere a problem between Mac and Windows:

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-cli/src/create-cli.js#L27-L60

While i just read the code in this file are 3 different versions used for the current path

path.resolve('.')
process.cwd()
resolveCwd

And thatswhyinstalledGatsbyVersion maybe goes wrong somehow.

And the next guess is that something in the DEFAULT_BROWSERS is not working on windows on the local pc with is fixed with a custom browserslist entry

[narration-sd]

Hallo @muescha Michael, quickly here

You mean the browserlist mentioned here: Gatsbyjs Browser Support?

Yes -- in particular where it says 'By default, Gatsby emulates the following config:' etc,

This is what I am issue-ing, that it doesn't seem to do on Win10

Can you give your browserlist config you added to fix the problem?

Sure -- actually I'm changing over to the contemporary suggested config, much as in that article page.

What I was using that works always, but only if I manually provide it, usually in the package.json (formatted correctly), but for tests here in a .browserslistrc file, is:

last 2 versions
> 1%
not ie <= 10

Looking this up, though, showed a surprising thing.

I have a main actual Gatsby site which tests and demos my product, which originally began from the default two-page sample introducer. This 'compiles' fine for months, daily, for dev or build. But it does not seem to have any Browserslist info from me -- neither file nor in package.json.

So it looks like months ago, gatsby-cli did the right thing on Windows. But now, apparently not...

[muescha]

How about if you change it in the package.json to the DEFAULT_BROWSERS values for gatsbyjs version 1 and also for the version !=1

PS: i don‘t know so much if the values are used. But just i see they are different to the default ones

[narration-sd]

Hmm, I think something's missed in communcation here. My problem is not if I use my own browserslist configuration -- this works, whether in package.json or .browserslistrc. The issue is that no default browserslist configuration is present to allow npm run develop to run successfully in the project folder, after installing via gatsby new projectname.

I've just discovered something fascinating about this, though! If, you put in a .browserslistrc, and then do an npm run develop, we know this has success. But it does something else. After one run this way, you can delete the .browserslistrc -- and then npm run develop will succeed without it!!

I ran a find-exec-grep over the entire project folder, and don't find a string match to the temporary .browserslistrc content. So this is a big mystery. Where on earth (or with what encoding....) is the browserslist config saved??

I tried doing a manual gatsby clean, and verified the cache and public folders were gone, and still this mystery saved configuration (or something...) allowed the underlying gatsby develop to succeed.

I also believe, but am out of time today to recheck, that a npm run build on a fresh site without any browserslist config succeeded. If this is true, then I also think something has changed in the last few days.

All in all, it's getting to be clearer why you Gatsby devs think this works -- so many ways to falsely see expected results.... -- when it pretty clearly also does not actually work. Where a new Gatsby-ite is sure to find that....

[narration-sd]

Here's a log of the full process, showing the fail, the insertion of config, the success, the removal of config, and the success continuing after this removal anyway...

fresh-site.log

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[narration-sd]

surprised this isn't getting attention...this basic problem for Gatsby new apps continues to exist - just tried on latest gatsby/gatsby-cli,

You do understand, that new Gatsby users are going to be stopped by it??

[KyleAMathews]

@narration-sd no one else seems to be having this problem — I just ran:

gatsby new my-site
cd my-site
gatsby build

and it worked as expected.

We'd love to fix whatever is affecting you but we need more help from you to figure out how to reproduce the problem as it seems specific to a rare set of circumstances.

[KyleAMathews]

Is there anything unusual about your development environment?

We appreciate your interest in helping improve Gatsby!

[marcysutton]

@KyleAMathews they were on Windows. I'm going through the install process again on a new Windows machine since I opened this issue: #15529

I'll comment again when I know whether this issue comes up - the process is going pretty slow so far (nothing to do with Gatsby though)

[narration-sd]

@KyleAMathews We'd love to fix whatever is affecting you but [...] circumstances

Great -- let's do it!

Is there anything unusual about your development environment?

I really don't think so. As there's pretty continuous development on the machine, I update npm & -g, composer, etc. daily.

It is a Win10 i7 1903 machine, very up-to-date also on all Win, including yesterday's first tuesday updates.

What's above and file inclusions will give logs and a picture of what happens, but to cut to the chase, here's a log just made: gatsby-dev.log

Now, here's the one clue I noticed, once again also.

First, after this failed, logged run, I pasted some browserslist config into the package.json, and unsurprisingly, then gatsby develop ran fine, and served your demo blog app which I used gatsby new to create this time, just to see it wasn't something with the default default.

But the possible clue is this. As noted above, I removed the extra config, ran gatsby clean, and tried gatsby develop once more. And it ran fine, app serves, etc.. I tried before with find exec grep to discover where the browserslist config actually got stored, unsuccessful as it's probably compressed.

This odd behavior makes me think that @muescha Michael's observation above in
#14800 (comment) may be relevant, for the primary issue? And a sneak path is there which could confuse others later also, via the hidden save of no-longer-present config?

But again,

• doesn't work here
• no apparent reason
• I pretty firmly believe it did work fine, no extra browserslist config required, when I first started working with Gatsby months ago.

Regards,
Clive

[KyleAMathews]

In your log you posted in the past, it looks like you're working within Vagrant?

[KyleAMathews]

@wardpeet you have a windows machine right? Can you reproduce this?

[narration-sd]

@KyleAMathews no, this is totally Windows. I use Vagrant for the CMS app involved on another project. There's no Vagrant or config for it in this sample creation giving you today's log.

@marcysutton Thanks, Marcy!

[narration-sd]

@marcysutton that's a great plan to normalize instructions for Window, good work!

@KyleAMathews am aware @wardpeet 's in Belgium, so attendant on timezones for his input.

and a p.s. I always dev/build Gatsby in windows, just push the build result to a *nix box, vm or not.

[marcysutton]

I can't reproduce this on Windows 10–neither with the default starter nor the hello world starter. Is there anything else that's special about your setup? The only thing that comes to mind after reading through your info again is that I'm on a newer version of Node (12.6.0), where you were on Node 10. Can you try a newer version to see if that clears it up?

[narration-sd]

@marcysutton Well, this is kind of a puzzle, isn't it.

Actually, as above, I switched over to the 12.x node versions during the earlier conversations. I'm at 12.4.0/6.9.0 for node and npm at present. Nonetheless, I'll just now update to absolute latest, create a new test install due to the 'hidden remembering' problem, and see what happens....

[narration-sd]

...and, as expected, node 12.6.0/npm 6.9.0 made no difference - still the failure.

I did however resolve the mystery of why having browerslist config once mysteriously stores. With a better diff tool, I noted among other unexpected in node_modules its own .cache folder. In that, a folder for babel-loader, with lots of zipped-I think json files.

Deleting this node_modules\.cache cleared the memory, so that without my added config, the failure was back

@KyleAMathews maybe gatsby clean should zap this cache as well??

Open to suggestions what I could try to get to a reason your default config per #14800 (comment) seems to be bypassed?

[narration-sd]

@KyleAMathews @marcysutton @wardpeet Ok, call off the fire trucks, thanks indeed -- problem solved.

It was in my environment, with due apologies. Found after suitable wrestling with webpack, gatsby config, various google vagueness, etc.. Software.

Points:

• that particular error message it is known around these parts to be often or always quite bogus. You can start from what a *nix background would tell you about the text itself.
• Gatsby doc on adding/replacing webpack config via gatsby-node.js could be improved. Specifically, just how to set a basic webpack control flag like stats; { errorDetails: true } -- which would be an excellent added case?
• but the real problem was mine. I have a bad habit of moving questionable items to a folder above, just to save them while testing without -- which is meant to be temporary. It also sometimes happens that the wrong files get moved or copied by a slip on the trackpad. What I had done that cause this issue report is to have two files in a super directory - two levels up -- one named browserslist, the other browserslist.cmd. It looks like babel or perhaps browserslist itself sniffed them out.
• solution: remove those files, then install a fresh Gatsby project since I'd messed around too much within node_modules internal files while troubleshooting, and then gatsby develop etc. works just as it should.

Wishing you all a pleasant evening, and thanks again for jumping on this,
Clive

[narration-sd]

p.s. I'm thinking the bogus-looking error message might have been half-reasonable, as I think the problem indicated was that where babel/browserslist tried to use I think the non-.cmd bad file, it may not have had shelljs available, and thus couldn't run the indicated shell commands.

This internal environment issue might also have caused the broken message form, as Regex is involved, and numbers of backslashes matter. And, it's possible matters like this contribute to the reputation the error has for being bogus.

But to report such, and not give a stack trace, files listed, etc.. -- well, that's Webpack's fault I think, and not a good thing, is it. Cheers 🌞

[marcysutton]

Good to hear you figured it out! We’d love docs contributions for the things you thought could be improved. ✌️

[narration-sd]

Ok, yes, I was a little coy about that - I have my own product to get out. But I did spend an hour plus here quite late, and got something.

What it doesn't do is produce any extra useful information for the error this issue's been all about. I suspect we're stuck for that, and then there's the value of Github issues, because someone can google that phoney error message and find a line of solution here.

What it does do is provide your choice of Gatsby site stats from webpack builds, which is pretty popular information based on the npm downloads of the plugin its based upon. Chunk sizes and such.

The results will show up in logs/stats.json, so will be automatically ignored by the default .gitignore that gatsby-cli provides.

This should be validated by someone on your team who's well-versed in the areas, before making it into doc....

// add or merge into gatsby-node.js
// npm install -D stats-webpack-plugin

const StatsPlugin = require('stats-webpack-plugin');

exports.onCreateWebpackConfig = ({ stage, plugins, actions }) => {
  if (stage === 'build-javascript') {
    actions.setWebpackConfig({
      plugins: [
        new StatsPlugin('../logs/stats.json', {
          all: false,
          // choose your desired stats elements from stats-webpack-plugin doc
          assets: true,
          modules: true,
          chunks: true,
          errors: true,
          errorDetails: true
        })
      ]
    });
  }
};