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

feat: more debugging features #151

Open
calebfaruki opened this issue Dec 4, 2021 · 4 comments
Open

feat: more debugging features #151

calebfaruki opened this issue Dec 4, 2021 · 4 comments
Labels
enhancement New feature or request

Comments

@calebfaruki
Copy link

~/gatsby-project
cfaruki@website[imgix-gatsby !x] yarn start
yarn run v1.22.17
$ run-p start:**
$ yarn develop
$ yarn clean && gatsby develop --verbose
$ rimraf .cache public
verbose set gatsby_log_level: "verbose"
verbose set gatsby_executing_command: "develop"
verbose loading local command from: /Users/cfaruki/gatsby-project/node_modules/gatsby/dist/commands/develop.js
verbose running command: develop

verbose Transition to "initializing"
warn The following flag(s) found in your gatsby-config.js are not supported in your environment and will have no effect:
- DEV_SSR
info The following flags are active:
- FAST_DEV · Enable all experiments aimed at improving develop server start time.
- PRESERVE_FILE_DOWNLOAD_CACHE · (Umbrella Issue (https://gatsby.dev/cache-clearing-feedback)) · Don't delete the downloaded files cache when changing
gatsby-node.js & gatsby-config.js files.

There is one other flag available that you might be interested in:
- PARALLEL_SOURCING · EXPERIMENTAL · (Umbrella Issue (https://gatsby.dev/parallel-sourcing-feedback)) · Run all source plugins at the same time instead of
serially. For sites with multiple source plugins, this can speedup sourcing and transforming considerably.

success open and validate gatsby-configs, load plugins - 1.138s

 ERROR

(node:97162) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./public/" in the "exports" field module resolution of the package at
/Users/cfaruki/gatsby-project/node_modules/extract-files/package.json.
Update this package.json to use a subpath pattern like "./public/*".
(Use `node --trace-deprecation ...` to show where the warning was created)

info [@imgix/gatsby] Loaded plugin.
success onPreInit - 0.014s
success initialize cache - 0.076s
success copy gatsby files - 0.069s
verbose Attaching functions to development server
success Compiling Gatsby Functions - 0.240s
success onPreBootstrap - 0.252s
verbose Creating 5 worker
verbose Transition to "initializingData"
success createSchemaCustomization - 1.109s
verbose Transition to "initializingData" > "sourcingNodes"
verbose Checking for deleted pages
verbose Deleted 0 pages
verbose Found 0 changed pages
success Checking for changed pages - 0.003s
success source and transform nodes - 4.378s
verbose Transition to "initializingData" > "buildingSchema"
success building schema - 0.508s
verbose Transition to "initializingData" > "creatingPages"
success createPages - 0.135s
success createPagesStatefully - 0.158s
info Total nodes: 1069, SitePage nodes: 80 (use --verbose for breakdown)
verbose Number of node types: 10. Nodes per type: Directory: 38, File: 482, GraphQLSource: 1, ImageSharp: 272, Instagram: 6, MarkdownRemark: 158, Site: 1,
SiteBuildMetadata: 1, SitePage: 80, SitePlugin: 56
verbose Checking for deleted pages
verbose Deleted 0 pages
verbose Found 80 changed pages
success Checking for changed pages - 0.001s
verbose Transition to "initializingData" > "writingOutRedirects"
success write out redirect data - 0.003s
verbose Transition to "initializingData" > "done"
verbose Transition to "runningPostBootstrap"
success Build manifest and related icons - 0.118s
success onPostBootstrap - 0.121s
info bootstrap finished - 9.926s
verbose Transition to "runningQueries"
success onPreExtractQueries - 0.002s
success extract queries from components - 1.131s
verbose Transition to "runningQueries" > "waitingPendingQueries"
verbose Transition to "runningQueries" > "writingRequires"
success write out requires - 0.124s
verbose Transition to "runningQueries" > "calculatingDirtyQueries"
verbose Transition to "runningQueries" > "runningStaticQueries"
success run static queries - 0.282s - 10/10 35.51/s
verbose Transition to "runningQueries" > "runningPageQueries"
success run page queries - 0.014s - 2/2 141.85/s
verbose Transition to "runningQueries" > "waitingForJobs"
verbose Transition to "runningQueries" > "done"
verbose Transition to "startingDevServers"
verbose Attaching functions to development server

 ERROR

Error when resolving URL value for node type MarkdownRemarkFrontmatterMyCustomNode. This probably means that the getURL function in
gatsby-config.js is incorrectly set. Please read this project's README for detailed instructions on how to set this correctly.

Two things:

  1. The custom field configuration docs are not intuitive. Took me a couple hours of kicking the tires to figure out how it works.
  2. The above error only occurs at dev runtime. But there's no meaningful output. For projects at scale, this makes it frustratingly difficult to isolate the root cause of the graphql query failure. You should be able to see what part of the query failed.
@frederickfogerty
Copy link
Contributor

Hi @calebfaruki, thanks for opening this issue 🙌 I appreciate the critique here, and I can understand your frustration. I just wondered if you had any concrete suggestions for (1) to improve its intuitiveness? For (2), I'm not quite fully understanding your suggestion, could you please elaborate on it?

@calebfaruki
Copy link
Author

calebfaruki commented Dec 6, 2021

For point one, there should be better documentation. The examples are okay. But it's better to know what each field is doing and how to determine what value to put there.

---
templateKey: category-page
path: /path/to/page
title: My Category Page
heroImage:
  imageKey: MyImage.jpg # https://myhost.imgix.net/MyImage.jpg
  # fieldName value will be inserted by gatsby config.
  # Will have return value of GatsbyImageLike (see Typescript definition)
---

Here's my raw text

Corresponding gatsby configuration for custom field.

{
  // get the __typename value from parent node where the imgix data will be nested.
  nodeType: 'MarkdownRemarkFrontmatterHeroImage',
  // what is the adjacent field/resolver for creating referencing the image asset at the URL.
  getURL: (node) => node.imageKey,
  // this is the name of the field that is created within the parent node specified in nodeType
  fieldName: 'imgixImage',
},

Regarding point number two, the best fundamental thing would be for the getURL error to give expected versus actual output.

If it errs on a markdown content entry, it should say what the value is, which piece of content it failed on, and what it would expect the result to look like. An example accompanying the expected data type would also help contextualize the hint.

Error when resolving URL value for node type MarkdownRemarkFrontmatterMyCustomNode. This probably means that the getURL function in
gatsby-config.js is incorrectly set. Please read this project's README for detailed instructions on how to set this correctly.

For the following query:
query {
  MyCategoryPages {
    heroImage {
      imgixImage
    }
  }
}

Expected: File name.
Actual: <whatever value getURL is actually returning>

@frederickfogerty
Copy link
Contributor

Thanks for the extra suggestions here @calebfaruki! I will raise this with my team and see if we can prioritise updating these. Of course, a PR here is also welcome and I will be prompt with reviews and feedback. Let me know if this is something you are interested in.

@luqven
Copy link
Contributor

luqven commented Sep 30, 2022

Hey @calebfaruki,

I wanted to take a second to follow up on this. We agree it would be nice to have better-debugging features but don't have the bandwidth to tackle this just yet.

I'm going to leave this issue open and in the meantime encourage folks who are interested in seeing this added to comment and react on this post. This will help us prioritize this work next time we review outstanding tasks.

As always, a PR is also welcome and we'll be sure to provide guidance and feedback.

Thanks again for opening this issue and we'll comment on this issue whenever there's been a change in status.

@luqven luqven changed the title Needs better debugging features feat: more debugging features Sep 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants