profile
viewpoint
Michal Piechowiak pieh Wroclaw, Poland Twitter: @mipiechowiak

alcoheca/xbmc 3

XBMC Main Repository

pieh/better-opn 0

A better opn. Reuse the same tab on Chrome for 👨‍💻.

pieh/codemirror-graphql 0

GraphQL mode and helpers for CodeMirror.

pull request commentgatsbyjs/gatsby

fix(babel-preset-gatsby-package) adjust loose mode configuration to comply with babel constraint

Since @babel/preset-env imports those plugins itself, maybe @babel/plugin-proposal-class-properties could just be removed from the list?

We have shippedProposals: true in our preset-env settings which make it so preset doesn't add few of plugins (including class properties ones), so I think the change in this PR is actually least invasive one (tho I need to look up meaning of loose setting :) )

That said - I wonder if gatsby-package is right preset we need to look at? Usually this one is used only to build package to publish to npm and shouldn't be causing problem in runtime? https://github.com/Js-Brecht/gatsby-plugin-ts-config/issues/11 is the issue I refer to - unless your plugin make use of that gatsby-package preset - I would expect stuff to be problematic with babel-preset-gatsby one?

Js-Brecht

comment created time in 8 hours

pull request commentgatsbyjs/gatsby

feat(gatsby-remark-embed-snippet): Add the ability to embed named snippets

I notice that the lint check is failing due to an extra space in docs/blog/2020-05-22-happy-fifth-bday-gatsby/index.md. If I fix that, the lint passes - should I commit that change into this PR?

You can merge master branch of gatsbyjs/gatsby into your branch and push it (lint was fixed in master already).

Assuming origin = gatsbyjs/gatsby:

git fetch origin master
git merge origin/master
git push <your_fork> packages/add-named-snippets

should fix lint problems

Alternatively - you can go ahead and fix the lint separately in your branch - because it was fixed already in master - this change should not show in PR view

BobWall23

comment created time in 8 hours

Pull request review commentgatsbyjs/gatsby

feat(gatsby-remark-embed-snippet): Add the ability to embed named snippets

 module.exports = ({ markdownAST, markdownNode }, { directory } = {}) => {           .split(`\n`)           .filter((_, lineNumber) => lines.includes(lineNumber + 1))           .join(`\n`)+      } else if (sname.length) {+        let index1 = code.indexOf(`start-snippet{${sname}}`)+        if (index1 > -1) {+          let index2 = code.indexOf(`\n`, index1)+          if (index2 > -1) {+            index2 = index2 + 1 // skip the newline

Ah, right - this makes sense.

I do wonder if we could make the code more concise (and drop index1 up to index4 which makes it bit hard to follow) in the process:

what instead of using (last)indexOf we would use regular expressions:

const startingSnippetDirectiveMatcher = new RegExp(`start-snippet{${sname}}[^\r\n]*[\r\n](.*)`, `gs`)
const startSnippetMatch = startingSnippetDirectiveMatcher.exec(code)
if (startSnippetMatch?.length >= 2) {
  code =  startSnippetMatch[1]
}

const endingSnippetDirectiveMatcher = new RegExp(`(.*)[\r\n][^\r\n]*end-snippet{${sname}}`, `gs`)
const endSnippetMatch = endingSnippetDirectiveMatcher.exec(code)
if (endSnippetMatch?.length >= 2) {
  code =  endSnippetMatch[1]
}

This would pick next lines after start-snippet{name} in first step and lines before end-snippet in the second.

Alternative is to keep current code - just move it to some utility file to not show all the "gruesome" details of extracting snippets in main file which should be bit more high level than details like.

I'm fine with both approaches

BobWall23

comment created time in 8 hours

Pull request review commentgatsbyjs/gatsby

feat(gatsby-remark-embed-snippet): Add the ability to embed named snippets

 module.exports = ({ markdownAST, markdownNode }, { directory } = {}) => {           .split(`\n`)           .filter((_, lineNumber) => lines.includes(lineNumber + 1))           .join(`\n`)+      } else if (sname.length) {+        let index1 = code.indexOf(`start-snippet{${sname}}`)+        if (index1 > -1) {+          let index2 = code.indexOf(`\n`, index1)+          if (index2 > -1) {+            index2 = index2 + 1 // skip the newline

why extra step to go to next line is needed and not just from start-snippet to end-snippet?

BobWall23

comment created time in 16 hours

Pull request review commentgatsbyjs/gatsby

feat(gatsby-remark-embed-snippet): Add the ability to embed named snippets

 function App() {   ) } ```++### Specifying snippets by name++As an alternative to selecting a range of lines from a file, you can add `start-snippet{snippet-name}` and `end-snippet{snippet-name}` in comments in your files. The inclusion of a name for a snippet allows you to create an example file that contains multiple snippets that you reference from different places.++You specify that you want to only include a named snippet from the embed using the syntax `{snippet: "snippet-name"}`.++**Rust example**:++```markdown+The function to use is:++`embed:api.rs{snippet: "funcA"}`++And it is invoked via++`embed:api.rs{snippet: "invokeA"}`+```++With this example file `api.rs`:++```rust+// begin-snippet{funcA}+fn factorial(x: u8) -> u32 {+    if x <= 1 { 1u32 }+    else { (x as u32) * factorial(x - 1) }+}+// end-snippet{funcA}++pub fn main() -> () {+    let x: u8 = 5;+    // begin snippet{invokeA}
    // start-snippet{invokeA}
BobWall23

comment created time in 16 hours

Pull request review commentgatsbyjs/gatsby

feat(gatsby-remark-embed-snippet): Add the ability to embed named snippets

 function App() {   ) } ```++### Specifying snippets by name++As an alternative to selecting a range of lines from a file, you can add `start-snippet{snippet-name}` and `end-snippet{snippet-name}` in comments in your files. The inclusion of a name for a snippet allows you to create an example file that contains multiple snippets that you reference from different places.++You specify that you want to only include a named snippet from the embed using the syntax `{snippet: "snippet-name"}`.++**Rust example**:++```markdown+The function to use is:++`embed:api.rs{snippet: "funcA"}`++And it is invoked via++`embed:api.rs{snippet: "invokeA"}`+```++With this example file `api.rs`:++```rust+// begin-snippet{funcA}
// start-snippet{funcA}

Code is using start-snippet so adjusting docs part to match it

BobWall23

comment created time in 16 hours

push eventgatsbyjs/gatsby

Timothy Gu

commit sha 19dc8a9649d58194a7ba5a76d5abba6dd0545e78

fix(gatsby-recipes): move strip-ansi to dependencies (#24687) strip-ansi is used by src/providers/utils/get-diff.js, which makes it a dependency. Refs: #20949

view details

push time in 9 hours

PR merged gatsbyjs/gatsby

fix(gatsby-recipes): move strip-ansi to dependencies topic: recipes

<!-- Have any questions? Check out the contributing docs at https://gatsby.dev/contribute, or ask in this Pull Request and a Gatsby maintainer will be happy to help :) -->

<!-- Is this a blog post? Check out the docs at https://www.gatsbyjs.org/contributing/blog-contributions/, and please mention if the blog post is pre-approved by someone from Gatsby. -->

Description

<!-- Write a brief description of the changes introduced by this PR --> strip-ansi is used by gatsby-recipes/src/providers/utils/get-diff.js, which makes it a dependency rather than devDependency. Make it so.

Related Issues

Addresses #20949

<!-- Link to the issue that is fixed by this PR (if there is one) e.g. Fixes #1234

Link to an issue that is partially addressed by this PR (if there are any) e.g. Addresses #1234

Link to related issues (if there are any) e.g. Related to #1234 -->

+1 -1

0 comment

1 changed file

TimothyGu

pr closed time in 9 hours

Pull request review commentgatsbyjs/gatsby

feat(gatsby): Add state machine services

+import { IBuildContext } from "../state-machines/develop"

we don't have this file in PR (hence no types)

ascorbic

comment created time in 10 hours

Pull request review commentgatsbyjs/gatsby

feat(gatsby): Add state machine services

+import { processStaticQueries } from "../query"+import { IBuildContext } from "../state-machines/develop"+import reporter from "gatsby-cli/lib/reporter"++export async function runStaticQueries({+  parentSpan,+  queryIds,+  store,+}: IBuildContext): Promise<object> {+  let results = new Map()+  if (!queryIds || !store) {+    return { results: [] }+  }+  const { staticQueryIds } = queryIds+  const state = store.getState()+  const activity = reporter.createProgress(+    `run static queries`,+    staticQueryIds.length,+    0,+    {+      id: `static-query-running`,+      parentSpan,+    }+  )++  if (staticQueryIds.length) {+    activity.start()+    results = await processStaticQueries(staticQueryIds, {+      state,+      activity,+    })+  }++  activity.done()+  return { results }+}

Side note - we don't really have to split queries into page and static queries anymore - might be fine to merge run-page-queries and run-static-queries together? (not necessarily in this PR)

ascorbic

comment created time in 10 hours

Pull request review commentgatsbyjs/gatsby

feat(gatsby): Add state machine services

+import { IBuildContext } from "../state-machines/develop"++import reporter from "gatsby-cli/lib/reporter"+import { extractQueries as extractQueriesAndWatch } from "../query/query-watcher"+import apiRunnerNode from "../utils/api-runner-node"++export async function extractQueries({+  parentSpan,+}: IBuildContext): Promise<void> {+  const activity = reporter.activityTimer(`onPreExtractQueries`, {+    parentSpan,+  })+  activity.start()+  await apiRunnerNode(`onPreExtractQueries`, {+    parentSpan: activity.span,+  })+  activity.end()++  await extractQueriesAndWatch({ parentSpan })+}

I assume this service would be called whenever we get into extractingQueries state - so it's not just first/initial one?

Showing activity (less important) and calling onPreExtractQueries each time we run this will change semantics of current API a bit (we only call it once - in extraction step we call explicitly during bootstrap)

ascorbic

comment created time in 10 hours

Pull request review commentgatsbyjs/gatsby

feat(gatsby): Add state machine services

+import { calcInitialDirtyQueryIds, groupQueryIds } from "../query"+import { IBuildContext } from "../state-machines/develop"++export interface IGroupedQueryIds {+  pageQueryIds: string[]+  staticQueryIds: string[]+}++export async function calculateDirtyQueries({+  store,+  filesDirty,+}: IBuildContext): Promise<{+  queryIds: IGroupedQueryIds+}> {+  const state = store?.getState()+  if (filesDirty) {+    // Do stuff+  }

Will we actually get list of dirty files in develop?

ascorbic

comment created time in 10 hours

Pull request review commentgatsbyjs/gatsby

chore(gatsby): Optimise create page action validation

+import path from "path"+import fs from "fs-extra"+import { IGatsbyPage } from "../redux/types"++const validationCache = new Map<string, boolean>()++interface IErrorMeta {+  id: string+  context: Record<string, unknown>+}++export function validatePageComponent(+  page: IGatsbyPage,+  directory: string,+  pluginName: string+): { message?: string; error?: IErrorMeta; panicOnBuild?: boolean } {+  const { component } = page+  if (!component) {+    throw new Error(`11322`)+  }+  if (validationCache.has(component)) {+    return {}+  }+  if (!path.isAbsolute(component)) {+    return {+      error: {+        id: `11326`,+        context: {+          pluginName: name,

We are not passing name here from createPage action

ascorbic

comment created time in 10 hours

Pull request review commentgatsbyjs/gatsby

feat(gatsby): Add state machine services

+import { IBuildContext } from "../state-machines/develop"+import sourceNodesAndGc from "../utils/source-nodes"+import reporter from "gatsby-cli/lib/reporter"+import { findChangedPages } from "../utils/check-for-changed-pages"++export async function sourceNodes({+  parentSpan,+  webhookBody,+  store,+}: IBuildContext): Promise<{+  changedPages: string[]+  deletedPages: string[]+} | void> {+  if (!store) {+    reporter.panic(`No redux store`)+    return void 0+  }+  const activity = reporter.activityTimer(`source and transform nodes`, {+    parentSpan,+  })+  console.log({ webhookBody })+  activity.start()+  const currentPages = new Map(store.getState().pages)+  await sourceNodesAndGc({+    parentSpan: activity.span,+    deferNodeMutation: !!(webhookBody && Object.keys(webhookBody).length),+    webhookBody,+  })+  reporter.info(`Checking for deleted pages`)++  const tim = reporter.activityTimer(`Checking for changed pages`)+  tim.start()++  const { changedPages, deletedPages } = findChangedPages(+    currentPages,+    store.getState().pages+  )

I assume this is to handle case of creating / deleting pages in response to node creation/deletion ? Would be great if we could add some comments why we do anything about pages and "source-nodes"

ascorbic

comment created time in 11 hours

Pull request review commentgatsbyjs/gatsby

feat(gatsby): Add state machine services

+import { IBuildContext } from "../state-machines/develop"++import reporter from "gatsby-cli/lib/reporter"+import apiRunnerNode from "../utils/api-runner-node"++import {+  deleteUntouchedPages,+  findChangedPages,+} from "../utils/check-for-changed-pages"

This utility seems to be missing in branch

ascorbic

comment created time in 11 hours

Pull request review commentgatsbyjs/gatsby

chore(gatsby): Export and improve types

 import { emitter, store } from "../redux"  import { waitUntilAllJobsComplete as waitUntilAllJobsV2Complete } from "./jobs-manager" -export const waitUntilAllJobsComplete = (): Promise<void> => {+export const waitUntilAllJobsComplete = (): Promise<any> => {

This is preparing for follow up PRs where returned value is actually meaningful (hence no void, but also not concrete types just yet?

ascorbic

comment created time in 11 hours

push eventgatsbyjs/gatsby

Sidhartha Chatterjee

commit sha 41d6849d5a6cf49a12e4f121d3046593a3b0922d

Traverse upwards from components instead of downwards from templates

view details

Michal Piechowiak

commit sha d69ce482e064431bf8390b51f5f1fbcef372cee1

return pageResources in loader

view details

Michal Piechowiak

commit sha ab2d55a279b3355aa02929cc560c9c6ee2fb7d36

support static queries, fix windows

view details

push time in 15 hours

pull request commentgatsbyjs/gatsby

feat(gatsby-remark-embed-snippet): Add the ability to embed named snippets

I wonder if I blew the commits by not using the conventional commit standard? I was thinking I just needed to worry about the pull request, not the individual commits to my fork. Hopefully that is correct.

This is correct - we are "squashing and merging", so single commit will end up in master - and if there is more than 1 commit in PR - PR title is used

BobWall23

comment created time in 16 hours

Pull request review commentgatsbyjs/gatsby

fix(gatsby-plugin-preact): add preact to framework bundle

 exports.onCreateWebpackConfig = ({ stage, actions, getConfig }) => {     })   } +  // add preact to the framework bundle+  if (stage === `build-javascript`) {+    const webpackConfig = getConfig()+    if (+      webpackConfig?.optimization?.splitChunks?.cacheGroups?.framework?.test+    ) {+      const frameworkRegex =+        webpackConfig?.optimization?.splitChunks?.cacheGroups?.framework?.test
        webpackConfig.optimization.splitChunks.cacheGroups.framework.test

you check for existence in if condition - so no need to use optional chaining here again? This is especially "visible" when in next statement we assign something else here

wardpeet

comment created time in 4 days

Pull request review commentgatsbyjs/gatsby

fix(gatsby-plugin-preact): add preact to framework bundle

 exports.onCreateWebpackConfig = ({ stage, actions, getConfig }) => {     })   } +  // add preact to the framework bundle+  if (stage === `build-javascript`) {+    const webpackConfig = getConfig()+    if (+      webpackConfig?.optimization?.splitChunks?.cacheGroups?.framework?.test

We transpile src and babel-preset-gatsby-package handles optional chaining, so we are good here

wardpeet

comment created time in 4 days

issue commentgatsbyjs/gatsby

createRemoteFileNode doesn't use inferred fileType to check existence

Thanks! Opened pull request with proposed fix - https://github.com/gatsbyjs/gatsby/pull/24613

thomascorthouts

comment created time in 4 days

PR opened gatsbyjs/gatsby

fix(gatsby-source-filesystem): fix extension guessing on warm cache

Description

We have logic to auto-guess extension if it can't be derived from url provide to createRemoteFileNode. This currently doesn't work on warm cache, because 304 reponses don't have body, so temp file is 0 bytes and there is nothing to guess extension from. To fix that we cache extension guessed on initial 200 response and use it whenever we get 304 response for same url.

Related Issues

Fixes #24453

+15 -7

0 comment

1 changed file

pr created time in 4 days

create barnchgatsbyjs/gatsby

branch : crfn-store-and-reuse-found-extension-on-304

created branch time in 4 days

pull request commentgatsbyjs/gatsby

fix(gatsby): show correct `serve` info when running on another port

@thefrontendwizard We use https://www.npmjs.com/package/gatsby-dev-cli for "transporting" changes from monorepo to test sites (without publishing to npm etc)

thefrontendwizard

comment created time in 4 days

push eventgatsbyjs/gatsby

Juliano Rafael

commit sha 3717ad6638c9d2c60fe45f169919a01032ca7b07

fix(gatsby): show correct `serve` info when running on another port (#24591)

view details

push time in 4 days

PR merged gatsbyjs/gatsby

fix(gatsby): show correct `serve` info when running on another port status: needs core review topic: cli

Description

use mutated port variable to generate the urls that inform the user about where is the server running.

Related Issues

Fixes #24518

+1 -1

0 comment

1 changed file

thefrontendwizard

pr closed time in 4 days

issue closedgatsbyjs/gatsby

`gatsby serve` correctly serves on 9001 when 9000 is occupied but reports incorrectly

<!-- Please fill out each section below, otherwise, your issue will be closed. This info allows Gatsby maintainers to diagnose (and fix!) your issue as quickly as possible.

Useful Links:

  • Documentation: https://www.gatsbyjs.org/docs/
  • How to File an Issue: https://www.gatsbyjs.org/contributing/how-to-file-an-issue/

Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues --> image

Description

when gatsby serve conflicts it says it's serving on the wrong port

Steps to reproduce

run gatsby serve in on projects run again in another project respond with y when asked if gatsby should use a different port

Expected result

serve on port 9001 and say so

Actual result

serves on port 9001 but says it's serving on port 9000

Environment

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

System: OS: Windows 10 10.0.18363 CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz Binaries: Node: 10.20.1 - C:\Program Files\nodejs\node.EXE Yarn: 1.22.4 - ~\AppData\Roaming\npm\yarn.CMD npm: 6.14.4 - C:\Program Files\nodejs\npm.CMD Languages: Python: 3.7.2 Browsers: Edge: 44.18362.449.0 npmPackages: gatsby: ^2.22.5 => 2.22.5 gatsby-image: ^2.4.5 => 2.4.5 gatsby-plugin-create-client-paths: ^2.3.2 => 2.3.2 gatsby-plugin-google-analytics: ^2.3.2 => 2.3.2 gatsby-plugin-manifest: ^2.4.8 => 2.4.8 gatsby-plugin-material-ui: ^2.1.8 => 2.1.8 gatsby-plugin-react-helmet: ^3.3.2 => 3.3.2 gatsby-plugin-sass: ^2.3.2 => 2.3.2 gatsby-plugin-sharp: ^2.6.8 => 2.6.8 gatsby-source-filesystem: ^2.3.7 => 2.3.7 gatsby-transformer-sharp: ^2.5.3 => 2.5.3

closed time in 4 days

goleary

PR merged gatsbyjs/gatsby

fix(gatsby-dev-cli): show spawned processes output unless `--quiet` is used type: maintenance

Description

gatsby-dev-cli is currently hiding output of various yarn commands we run under the hood unless DEBUG env var is set - this was done to prevent quite large console spam in case we need to go through verdaccio path, but tradeoff of frustration when something fails without clear reason is not worth having clean terminal output.

With this PR output of commands is hidden only when using --quiet flag. And if we hit errors with --quiet flag there is hopefully helpful message to drop --quiet switch to see the output.

+30 -7

0 comment

4 changed files

pieh

pr closed time in 4 days

push eventgatsbyjs/gatsby

Michal Piechowiak

commit sha 69383a8d89c504cc0da91e37a9b9b721954086b3

fix(gatsby-dev-cli): show spawned processes output unless `--quiet` is used (#24607) * fix(gatsby-dev-cli): show spawned processes output unless `--quiet` is used * fix test

view details

push time in 4 days

Pull request review commentgatsbyjs/gatsby

fix(gatsby-dev-cli): support workspaces in yarn@1.22

 const installPackages = async ({       { stdio: `pipe` },     ]) -    const workspacesLayout = JSON.parse(JSON.parse(stdout).data)+    let workspacesLayout+    try {+      workspacesLayout = JSON.parse(JSON.parse(stdout).data)+    } catch (e) {+      /*+      Yarn 1.22 doesn't output pure json - it has leading and trailing text:+      ```+      $ yarn workspaces info --json+      yarn workspaces v1.22.0+      {+        "z": {+          "location": "z",+          "workspaceDependencies": [],+          "mismatchedWorkspaceDependencies": []+        },+        "y": {+          "location": "y",+          "workspaceDependencies": [],+          "mismatchedWorkspaceDependencies": []+        }+      }+      Done in 0.48s.+      ```+      So we need to do some sanitization. We find JSON by matching substring+      that starts with `{` and ends with `}`+    */++      const regex = /^[^{]*({.*})[^}]*$/gs+      const sanitizedStdOut = regex.exec(stdout)+      if (sanitizedStdOut?.length >= 2) {+        // pick content of first (and only) capturing group+        const jsonString = sanitizedStdOut[1]+        workspacesLayout = JSON.parse(jsonString)

Added some try/catching and just log some details specific to this code path.

We will exit with generic error message below

pieh

comment created time in 4 days

push eventgatsbyjs/gatsby

Michal Piechowiak

commit sha eb2037ecfe0f7096ed71584b6c13a374666a7741

try/catch parsing "sanitized" output

view details

push time in 4 days

push eventgatsbyjs/gatsby

Michal Piechowiak

commit sha 1ad19270e13067958725d0e3c12469f46aca23c8

fix test

view details

push time in 4 days

Pull request review commentgatsbyjs/gatsby

fix(gatsby-dev-cli): support workspaces in yarn@1.22

 const installPackages = async ({       { stdio: `pipe` },     ]) -    const workspacesLayout = JSON.parse(JSON.parse(stdout).data)+    let workspacesLayout+    try {+      workspacesLayout = JSON.parse(JSON.parse(stdout).data)+    } catch (e) {+      /*+      Yarn 1.22 doesn't output pure json - it has leading and trailing text:

Use the --silent flag to remove the header / footer from the output

Doesn't seem to work in 1.22 - in fact neither silent nor json really do - using yarn workspaces info, yarn workspaces info --json, yarn workspaces info --silent, yarn workspaces info --json --silent all output same thing:

$ yarn workspaces info --silent
yarn workspaces v1.22.0
warning package.json: No license field
{
  "z": {
    "location": "z",
    "workspaceDependencies": [],
    "mismatchedWorkspaceDependencies": []
  },
  "y": {
    "location": "y",
    "workspaceDependencies": [],
    "mismatchedWorkspaceDependencies": []
  }
}
Done in 0.20s.

I think in 1.x the --json flag will wrap the output into a "log" property which you probably don't want

It does in <1.22 - it has { type: "log", data: "stringified-json" } (hence grabbing .data in JSON.parse(stdout).data), it doesnt in >=1.22 (or at least in 1.22.0).

In any case - this is really not looking to make this 100% reliable - I do want to explore using Yarn 2 with yarn link that uses portals protocol - like you did for "e2e pnp tests" (just gatsby-dev-cli is always on backlog and is never firest fire to work on, so it's just matter of not being able to spend more time on it)

pieh

comment created time in 4 days

PR opened gatsbyjs/gatsby

fix(gatsby-dev-cli): support workspaces in yarn@1.22

Description

When using yarn@1.22 it has different shape of yarn workspaces info --json command than previous versions of yarn - because gatsby-dev-cli relies on this output when running it in workspaces - we need some error catching / sanitization

+43 -1

0 comment

1 changed file

pr created time in 4 days

create barnchgatsbyjs/gatsby

branch : gdc-yarn-1-22

created branch time in 4 days

PR opened gatsbyjs/gatsby

fix(gatsby-dev-cli): show spawned processes output unless `--quiet` is used

Description

gatsby-dev-cli is currently hiding output of various yarn commands we run under the hood unless DEBUG env var is set - this was done to prevent quite large console spam in case we need to go through verdaccio path, but tradeoff of frustration when something fails without clear reason is not worth having clean terminal output.

With this PR output of commands is hidden only when using --quiet flag. And if we hit errors with --quiet flag there is hopefully helpful message to drop --quiet switch to see the output.

+29 -7

0 comment

3 changed files

pr created time in 4 days

push eventgatsbyjs/gatsby

Michal Piechowiak

commit sha 7fd2b0a556ae3939fdf41212c9892f4e033b357f

fix(gatsby-dev-cli): show spawned processes output unless `--quiet` is used

view details

push time in 4 days

create barnchgatsbyjs/gatsby

branch : gdc-be-more-chatty

created branch time in 4 days

issue commentgatsbyjs/gatsby

After update Gatsby from 2.21.17 to 2.22.12 it doesn't work anymore

What are node version you are using? We also do need some kind of reproduction for it.

alexandresgf

comment created time in 4 days

push eventgatsbyjs/gatsby

Michal Piechowiak

commit sha b5e4fb5a18c5194e90bc6e003023acdb52575ae1

unify page-data and hot data updates

view details

Mikhail Novikov

commit sha 7ffe01d6132aee7495abbb43627ae644aa3467e6

WIP

view details

Michal Piechowiak

commit sha 2db8527ad73dad3fa4fc8c6a659b3a301143660b

add one-stop shop in loader for loading modules, so socketio can use it on hot date updates

view details

Michal Piechowiak

commit sha 062bc1c04ee77417967562f15edae0ca86969b36

Merge remote-tracking branch 'origin/wip-page-data-processors-and-components-from-graphql' into wip-page-data-processors-and-components-from-graphql

view details

push time in 4 days

issue commentgatsbyjs/gatsby

Can't debug gatsby develop in v2.22.4

Not ideal - but until we get this fixed / provide nicer solution - as workaround, instead of using node --inspect(-brk), "monkey-patchgatsby/dist/commands/develop.js` and change this line: https://github.com/gatsbyjs/gatsby/blob/ad5f9af897257596069f9e8aad307215d98471af/packages/gatsby/src/commands/develop.ts#L71

to this.process = spawn(node, [--inspect-brk, tmpFileName], {, then use regular gatsby develop and use either auto attach in vscode (or if it can't find process use "attach to node process") / regular chrome dev tools way of attaching

JacoboGallardo

comment created time in 4 days

pull request commentgatsbyjs/gatsby

fix(gatsby-source-filesystem) Remote File Node env variables

That said - I do see value in users being able to define their own, so I'm overall OK with this, but we should document it somewhere in gatsby-source-filesystem/README.md.

We have note:

To prevent concurrent requests overload of processRemoteNode, you can adjust the 200 default concurrent downloads, with GATSBY_CONCURRENT_DOWNLOAD environment variable.

It is currently bit weirdly placed in "Options" section, but it's really just "option" for createRemoteFileNode and not plugin option. So what I would suggest is add "Troubleshooting" section below docs for createRemoteFileNode, mention problem (ideally with example error you are getting on flaky connection so users can find it when searching for this speciffic error) and list available env vars with some explanation and their default values

webbugt

comment created time in 5 days

pull request commentgatsbyjs/gatsby

fix(gatsby-source-filesystem) Remote File Node env variables

What values you are using now? I wonder if we should just not bump "defaults", so this can be more failure-proof out of the box for flaky connections.

webbugt

comment created time in 5 days

issue commentgatsbyjs/gatsby

createRemoteFileNode doesn't use inferred fileType to check existence

Hmm I actually can't reproduce it anymore. I was getting different error because https://fakeimg.pl/300x300/ url can't be resolved now (no DNS entry anymore? 🤔) I tried it few days ago and then could reproduce, but couldn't investigate yet and now reproduction doesn't work anymore :/

thomascorthouts

comment created time in 5 days

issue commentgatsbyjs/gatsby

createRemoteFileNode doesn't use inferred fileType to check existence

Thanks for report! I can reproduce this locally, and investigating now

thomascorthouts

comment created time in 5 days

pull request commentgatsbyjs/gatsby

fix(gatsby): Turn off react/jsx-pascal-case in ESLint to fix Theme-UI warnings

I think https://github.com/yannickcr/eslint-plugin-react/pull/2638 (recent change to react/jsx-pascal-case rule) might be what changed here.

So previously <Styled.p> was really testing just Styled part (which is PascalCase). After that PR was merged and published - it now checks p (which is not PascalCase).

I think the rule is way too opinionated to stay by default, so turning it off in general seems like good idea

ehowey

comment created time in 5 days

issue commentgatsbyjs/gatsby

Something went wrong installing the "sharp" module

Are you able to share your project so we can try to reproduce? Can you try running npm ls sharp? Also output of npm rebuild --verbose sharp could be helpful.

hsnyc

comment created time in 5 days

Pull request review commentgatsbyjs/gatsby

fix(gatsby-cli): Improve bottom status bar

 export interface IGatsbyCLIState {   activities: {     [id: string]: IActivity   }-  status: string+  status: ActivityStatuses | string

For this PR - maybe just make it stricter (ActivityStatuses | ""). And we can figure out using different fallback/default in another PR (it's not really concern of this PR IMO). What do you think about that?

LekoArts

comment created time in 5 days

Pull request review commentgatsbyjs/gatsby

fix(gatsby-cli): Improve bottom status bar

 export interface IGatsbyCLIState {   activities: {     [id: string]: IActivity   }-  status: string+  status: ActivityStatuses | string

Worth exploring using different default/fallback. In case there are problems - we could set type to ActivityStatuses | "" (more strict than string)

LekoArts

comment created time in 5 days

Pull request review commentgatsbyjs/gatsby

fix(gatsby-cli): Improve bottom status bar

 export interface IGatsbyCLIState {   activities: {     [id: string]: IActivity   }-  status: string+  status: ActivityStatuses | string

Do we need | string part? It feels like status should only have ActivityStatuses enum/union (same comment applies to other place where typing like that was added)

LekoArts

comment created time in 5 days

pull request commentgatsbyjs/gatsby

feat(gatsby-remark-embed-snippet): Add the ability to embed named snippets

Those were just examples - we might end up with them, but I'd like to encourage you to take a peek into what syntax conventions are used currently and maybe see if you can come up with better ones. You could take a look in both in gatsby-remark-embed-snippet and gatsby-remark-prismjs (because those 2 are pretty close together and both are used for similar results - showing some code blocks).

BobWall23

comment created time in 5 days

pull request commentgatsbyjs/gatsby

feat(gatsby-remark-embed-snippet): Add the ability to embed named snippets

Another thing is about marking snippets - using them with comments is fine, i just think we should use conventions we already have for line highlighting - so (potentially) // START SNIPPET bar -> // start-snippet{bar} - this is just so API is consistent and parts of it feel like they go well together.

Let me know what do you think

BobWall23

comment created time in 5 days

pull request commentgatsbyjs/gatsby

feat(gatsby-remark-embed-snippet): Add the ability to embed named snippets

This looks awesome!

I do however would want to discuss a bit way in which we specify snippet names to be used. Doing embed:file#SNsnippetName will work but I do wonder if we should try to take hint out of gatsby-remark-prismjs book and instead have something like embed:file{ snippet: "snippetName" } - for users not familiar with #SN<snippetName> syntax I think this will be easier to understand (and also give us room to implement other options/attributes in the future without overloading # (which can be reserved for line numbers)

BobWall23

comment created time in 5 days

push eventgatsbyjs/gatsby

Sidhartha Chatterjee

commit sha e9b5a49ca89ebf70b585bb8c6669f57a05c61953

Merge branch 'master' into static-queries-out-of-webpack

view details

Sidhartha Chatterjee

commit sha cbba074ebfc32def91834a19ee60aaaac8eab2a8

Fix linting

view details

Sidhartha Chatterjee

commit sha abef96b1f00a88224bcddc0818b0e95b7625b78c

Add back Error in useStaticQuery

view details

Michal Piechowiak

commit sha a6117ff5fa8813bf6a68d10a53d8798f6f112fb9

tmp

view details

Sidhartha Chatterjee

commit sha 25235bc3ebb6e8b4e6a297ea5b3038b813cf1acd

Persist and flush

view details

Michal Piechowiak

commit sha c0df08a50aaf34197d2dbaad0c4dbb1d81530b06

Merge remote-tracking branch 'origin/static-queries-out-of-webpack' into wip-query-webpack-modules-and-static-queries

view details

Michal Piechowiak

commit sha fb39a9e936b62e2b14869c6b62c3603280b1d95b

make page-data flushing work across the board

view details

push time in 6 days

push eventgatsbyjs/gatsby

Rikki Schulte

commit sha 90f60f0d710c0d96b4d727b3e1fc5f5dbf9a8c53

fix(graphiql-explorer): variables on edit (#24496) Co-authored-by: gatsbybot <mathews.kyle+gatsbybot@gmail.com>

view details

push time in 6 days

PR merged gatsbyjs/gatsby

fix(graphiql-explorer): variables on edit topic: GraphiQL* topic: themes

Description

Resolves #24250 by defaulting to undefined instead of null, so that the variables prop is not passed when unset

+2 -2

0 comment

1 changed file

acao

pr closed time in 6 days

issue closedgatsbyjs/gatsby

GraphiQL Query Variables are reset whenever query is updated

<!-- Please fill out each section below, otherwise, your issue will be closed. This info allows Gatsby maintainers to diagnose (and fix!) your issue as quickly as possible.

Useful Links:

  • Documentation: https://www.gatsbyjs.org/docs/
  • How to File an Issue: https://www.gatsbyjs.org/contributing/how-to-file-an-issue/

Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues -->

Description

I've noticed that the Query Variable field is reset every time I update a GraphQL query in the GraphiQL IDE.

Steps to reproduce

This can be reproduced on gatsby-starter-blog:

gatsby new graphiql-test https://github.com/gatsbyjs/gatsby-starter-blog
cd graphiql-test
gatsby develop

Open up GraphiQL: http://localhost:8000/___graphql and enter the following query:

query NewBeginningsPost($title: String!) {
  markdownRemark(frontmatter: {title: {eq: $title}}) {
    frontmatter {
      title
    }
  }
}

In the Query Variable section, add the following:

{
  "title": "New Beginnings"
}

Now update the query either directly in the query field, or using the Explorer menu on the left-hand side.

Expected result

The query variable field should not change unless we update it ourselves.

Actual result

Animated GIF showing query variables field being reset when the main query is updated

Environment

  System:
    OS: macOS 10.15.4
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
    Shell: 3.1.0 - /usr/local/bin/fish
  Binaries:
    Node: 12.16.3 - ~/.config/nvm/12.16.3/bin/node
    Yarn: 1.22.4 - ~/.config/nvm/12.16.3/bin/yarn
    npm: 6.14.4 - ~/.config/nvm/12.16.3/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 81.0.4044.138
    Edge: 81.0.416.77
    Safari: 13.1
  npmPackages:
    gatsby: ^2.21.37 => 2.21.37 
    gatsby-image: ^2.4.4 => 2.4.4 
    gatsby-plugin-feed: ^2.5.1 => 2.5.1 
    gatsby-plugin-google-analytics: ^2.3.1 => 2.3.1 
    gatsby-plugin-manifest: ^2.4.5 => 2.4.5 
    gatsby-plugin-offline: ^3.2.3 => 3.2.3 
    gatsby-plugin-react-helmet: ^3.3.1 => 3.3.1 
    gatsby-plugin-sharp: ^2.6.4 => 2.6.4 
    gatsby-plugin-typography: ^2.5.1 => 2.5.1 
    gatsby-remark-copy-linked-files: ^2.3.2 => 2.3.2 
    gatsby-remark-images: ^3.3.4 => 3.3.4 
    gatsby-remark-prismjs: ^3.5.1 => 3.5.1 
    gatsby-remark-responsive-iframe: ^2.4.2 => 2.4.2 
    gatsby-remark-smartypants: ^2.3.1 => 2.3.1 
    gatsby-source-filesystem: ^2.3.4 => 2.3.4 
    gatsby-transformer-remark: ^2.8.9 => 2.8.9 
    gatsby-transformer-sharp: ^2.5.2 => 2.5.2 

closed time in 6 days

lukebennett88

push eventgatsbyjs/gatsby

Blaine Kasten

commit sha 4156005e8539a774ea51986515c0b983f2869af1

fix(gatsby-cli): build properly in CI (#24511)

view details

push time in 6 days

PR merged gatsbyjs/gatsby

fix(gatsby-cli): build properly in CI status: triage needed

Description

Follow up #24285

With typegen now being part of build, we do need typescript to get tsc in node_modules/.bin. Otherwise if system doesn't have global typescript installed it will fail to build the package

+2 -1

0 comment

1 changed file

blainekasten

pr closed time in 6 days

Pull request review commentgatsbyjs/gatsby

fix(gatsby): log config validation errors

 export interface IGatsbyConfig {     title?: string     author?: string     description?: string+    sireUrl?: string

🙈 Thanks!

pieh

comment created time in 6 days

push eventgatsbyjs/gatsby

Maël Nison

commit sha dfc091f5483fad9b7ef2c025cf192854da88c347

test(e2e-pnp): widens the check pattern (#24470) * Widens the check pattern * Adds the @babel/helper-plugin-utils dep * Adds unified * Adds remark-mdx * Adds remark-parse * Adds hapi/hoek * Uses require stack rather than error * Removes extra file

view details

push time in 6 days

PR merged gatsbyjs/gatsby

fix(gatsby-recipes): add missing dependencies status: needs core review

Description

The current test pattern only reports webpack errors (ERROR #), not raw errors (Error: ...). This is typically not a problem because raw errors cause the process to abort, but it appears this isn't necessarily the case with gatsby-recipes:

https://app.circleci.com/pipelines/github/gatsbyjs/gatsby/41626/workflows/00a80c3c-735a-4bc0-8deb-c9a82d380fa4/jobs/418447/parallel-runs/0/steps/0-112

I'll also add in this diff the missing dependencies that didn't get reported until now.

+6 -1

2 comments

2 changed files

arcanis

pr closed time in 6 days

issue commentgatsbyjs/gatsby

contextModified is not properly re-evaluated if pages are deleted & created

Not deleting cause other problems (depending on scenarios) - keep in mind that there can be multiple plugins that implement onCreatePage hook:

All of them gets called when page is created. What we do when page is deleted in this hook - is we short circuit onCreatePage calls for the rest of plugin that implement onCreatePage (with now outdated page) and we create new API run for the new shape of page.

Additionally keep in mind that there are plugins that actually adjust path of a page (plugins like https://www.gatsbyjs.org/packages/gatsby-plugin-remove-trailing-slashes/ ), so the old page just can't stay around.

Using code change like one you suggested will also cause Gatsby to always re-run all queries on initial run (instead of rerunning subset of them that we know for sure need rerunning). This is not trivial problem to solve :( That's why I was exploring idea of delaying context comparison to after entire onCreatePage cascade finishes and not directly in createPage action creator - because there will be quite a bit of createPage calls called for "same page" with plugins making use of onCreatePage

xavivars

comment created time in 7 days

push eventalisson-suzigan/gatsby

Michal Piechowiak

commit sha 18e4195e2e243072e2ed6f4462cb9741b4c11cd7

Update packages/gatsby/src/redux/reducers/nodes-by-type.ts

view details

push time in 7 days

Pull request review commentgatsbyjs/gatsby

Widens the check pattern

+set -euxo pipefail+IFS=$'\n\t'++false | cat+false++echo ok

Is this file meant to go in?

arcanis

comment created time in 7 days

pull request commentgatsbyjs/gatsby

Widens the check pattern

Don't worry about windows_unit_tests failing (those are flaky tests, particularly on CI which are unrelated to your changes and also workarounded in https://github.com/gatsbyjs/gatsby/pull/24476 )

arcanis

comment created time in 7 days

Pull request review commentgatsbyjs/gatsby

fix(gatsby) api hooks: typescript return types

 export interface GatsbyNode {   setFieldsOnGraphQLNodeType?(     args: SetFieldsOnGraphQLNodeTypeArgs,     options: PluginOptions-  ): any+  ): GraphQLFieldConfigMap<any, any>   setFieldsOnGraphQLNodeType?(     args: SetFieldsOnGraphQLNodeTypeArgs,     options: PluginOptions-  ): Promise<any>+  ): Promise<GraphQLFieldConfigMap<any, any>>   setFieldsOnGraphQLNodeType?(     args: SetFieldsOnGraphQLNodeTypeArgs,     options: PluginOptions,     callback: PluginCallback-  ): void+  ): GraphQLFieldConfigMap<any, any>

for callback cases - return should be void - we instead use results from callback args, so potentially this should be something like this (and PluginCallback should be able to handle accepting result types, as it doesn't right now):

  setFieldsOnGraphQLNodeType?(
    args: SetFieldsOnGraphQLNodeTypeArgs,
    options: PluginOptions,
    callback: PluginCallback<GraphQLFieldConfigMap<any, any>>
  ): void
antoinerousseau

comment created time in 7 days

pull request commentgatsbyjs/gatsby

Fix develop SSL by moving the SSL setup to the proxy

From testing:

  • it seems we no longer get https urls in terminal output (You can now view gatsby-starter-blog in the browser. http://localhost:8000/ thingie), because this is displayed in develop-process and it checks for program.ssl which is not set in that process - we serialize program before this is added, but also it appears like we don't actually want inner server to run https, so we likely just want some boolean switch on program to let child process know which protocol to display)
  • I'm getting whole lot of SSL protocol errors - the resource it tries to connect to seems to be parent process websocket ssl-proto-error
mxstbr

comment created time in 7 days

Pull request review commentgatsbyjs/gatsby

chore(gatsby): Migrate reducers/nodes-by-type to TypeScript

-const getNodesOfType = (node, state) => {+import { IGatsbyNode, IGatsbyState, ActionsUnion } from "../types"++const getNodesOfType = (+  node: IGatsbyNode,+  state: IGatsbyState["nodesByType"]+): Map<string, IGatsbyNode> => {   const { type } = node.internal   if (!state.has(type)) {     state.set(type, new Map())   }-  return state.get(type)+  return state.get(type) as Map<string, IGatsbyNode> } -module.exports = (state = new Map(), action) => {+// module.exports = (
alisson-suzigan

comment created time in 7 days

push eventgatsbyjs/gatsby

Lennart

commit sha 6eb7290072a6739193c84d5453eb00bc7db08d10

fix(gatsby): Also traverse `FunctionDeclaration` (#24472) * fix: also traverse FunctionDeclaration * fix: var name + add test

view details

push time in 7 days

PR merged gatsbyjs/gatsby

fix(gatsby): Also traverse `FunctionDeclaration` status: needs core review

Description

Fixes https://github.com/gatsbyjs/gatsby/issues/24458

Relevant ASTExplorer: https://astexplorer.net/#/gist/a67d7a00ab34ed73711045da5ab348df/b2bc30b3e138e37851000e7c12770df01a71d29d

Previously it only checked for astPath.node.declaration.declarations[0].id.name, now it also checks for astPath.node.declaration.id.name.

+25 -7

1 comment

2 changed files

LekoArts

pr closed time in 7 days

issue closedgatsbyjs/gatsby

Exported functions in gatsby-ssr.js don't run

Description

If you create a gatsby-ssr.js like the following:

import React from 'react';
export function wrapPageElement({ props, element }) {
    throw new Error('boom');
}

This does nothing. wrapPageElement is never called.

As mentioned in #4718, you can get around this with:

import React from 'react';
export const wrapPageElement = ({ props, element }) => {
    throw new Error('boom');
}

And then you get the expected 'boom' error when you try to gatsby build.

Environment

  System:
    OS: macOS Mojave 10.14.6
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 12.14.0 - ~/.nvm/versions/node/v12.14.0/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - ~/benbria/loop-dashboard/node_modules/.bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Firefox: 76.0.1
  npmPackages:
    gatsby: ^2.22.9 => 2.22.9
    gatsby-image: ^2.3.4 => 2.3.4
    gatsby-plugin-create-client-paths: ^2.2.4 => 2.2.4
    gatsby-plugin-less: ^3.1.1 => 3.1.1
    gatsby-plugin-sharp: ^2.5.6 => 2.5.6
    gatsby-plugin-typescript: ^2.3.1 => 2.3.1
    gatsby-source-filesystem: ^2.2.4 => 2.2.4
    gatsby-transformer-sharp: ^2.4.6 => 2.4.6
  npmGlobalPackages:
    gatsby-cli: 2.11.2

closed time in 7 days

jwalton

PR opened gatsbyjs/gatsby

test(gatsby-recipes): increase timeout values

Description

We see alot of test flakiness in CircleCI with tests not finishing within 5s (default timeout for async tests). This one increase timeout in one of the test files that was very often failing based on just not resolving fast enough in CI

+4 -0

0 comment

1 changed file

pr created time in 7 days

create barnchgatsbyjs/gatsby

branch : moar-timeout

created branch time in 7 days

Pull request review commentgatsbyjs/gatsby

fix(gatsby): Also traverse `FunctionDeclaration`

 const staticallyAnalyzeExports = (modulePath, resolver = require.resolve) => {       isES6 = true     }, -    // get foo from `export const foo = bar`     ExportNamedDeclaration: function ExportNamedDeclaration(astPath) {-      const exportName = get(-        astPath,-        `node.declaration.declarations[0].id.name`-      )-      isES6 = true-      if (exportName) exportNames.push(exportName)+      const node = astPath.node.declaration++      // get foo from `export const foo = bar`+      if (+        get(astPath, `node.declaration.type`) === `VariableDeclaration` &&+        get(astPath, `node.declaration.declarations[0].id.name`)+      ) {+        isES6 = true+        exportNames.push(node.declarations[0].id.name)+      }++      // get foo from `export function foo()`+      if (+        get(astPath, `node.declaration.type`) === `FunctionDeclaration` &&+        get(astPath, `node.declaration.id.name`)+      ) {+        isES6 = true+        exportNames.push(node.id.name)

🤦 ops, my bad - but for my defence naming was confusing xD

LekoArts

comment created time in 7 days

Pull request review commentgatsbyjs/gatsby

feat(gatsby): Load static queries by the Gatsby runtime instead of webpack

 export const queryRunner = async (     resultHashes.set(queryJob.id, resultHash)      if (queryJob.isPage) {-      const publicDir = path.join(program.directory, `public`)-      const { pages } = store.getState()-      const page = pages.get(queryJob.id)-      await pageDataUtil.write({ publicDir }, page, result)+      // We need to save this temporarily in cache because+      // this might be incomplete at the moment+      // since it will not contain included static queries yet+      // Those will be added later and that is when this file will+      // be written to `public`+      const resultPath = path.join(+        program.directory,+        `.cache`,+        `json`,+        `${queryJob.id.replace(/\//g, `_`)}.json`

I think this is fine and implementation detail that shouldn't leak because it will stay in .cache.

sidharthachatterjee

comment created time in 7 days

Pull request review commentgatsbyjs/gatsby

feat(gatsby): Load static queries by the Gatsby runtime instead of webpack

 module.exports = async (program: IDevelopArgs): Promise<void> => {       webpackActivity = null     } +    if (isSuccessful) {+      const state = store.getState()+      const mapOfPagesToStaticQueryHashes = mapPagesToStaticQueryHashes(+        state,+        stats+      )++      const publicDir = path.join(program.directory, `public`)++      mapOfPagesToStaticQueryHashes.forEach(+        async (staticQueryHashes, pagePath) => {+          const page = state.pages.get(pagePath)++          await pageDataUtil.writePageData({ publicDir }, page, {+            staticQueryHashes,+          })+        }+      )+    }

This is (right now) only place where we write/update page-data files in develop mode.

There should be more triggers to rewrite those files:

  • when pure data change and doesn't cause webpack recompilation - we will write query result to .cache/json/X.json, but we weill not update corresponsing page-data.json file (until there is some potentially unrelated webpack recompilation).

It feels like we need to mark page-data.json files as potentially stale when we run queries, and then figure out if webpack needs recompilation or not to determine when to rewrite those

sidharthachatterjee

comment created time in 7 days

pull request commentgatsbyjs/gatsby

Provide refresh webhook headers in API

I wonder if at this point we should have just webhookRequest so plugins can reach to whatever request properties they need?

Simply007

comment created time in 7 days

Pull request review commentgatsbyjs/gatsby

fix(gatsby): Also traverse `FunctionDeclaration`

 const staticallyAnalyzeExports = (modulePath, resolver = require.resolve) => {       isES6 = true     }, -    // get foo from `export const foo = bar`     ExportNamedDeclaration: function ExportNamedDeclaration(astPath) {-      const exportName = get(-        astPath,-        `node.declaration.declarations[0].id.name`-      )-      isES6 = true-      if (exportName) exportNames.push(exportName)+      const node = astPath.node.declaration++      // get foo from `export const foo = bar`+      if (+        get(astPath, `node.declaration.type`) === `VariableDeclaration` &&+        get(astPath, `node.declaration.declarations[0].id.name`)+      ) {+        isES6 = true+        exportNames.push(node.declarations[0].id.name)+      }++      // get foo from `export function foo()`+      if (+        get(astPath, `node.declaration.type`) === `FunctionDeclaration` &&+        get(astPath, `node.declaration.id.name`)+      ) {+        isES6 = true+        exportNames.push(node.id.name)

Shouldn't this be

        exportNames.push(node.declaration.id.name)

?

LekoArts

comment created time in 7 days

push eventgatsbyjs/gatsby

Jeremy Albright

commit sha 36357ab81e931c27ec0b781193909d31ac434a65

fix(gatsby): add explicit dependency on `socket.io-client` and explicitly set `url-loader` fallback (#24465) * provide fully qualified path for url-loader's `fallback` * create resolution for `socket.io-client`, for import in `.cache/app.js` * include socket.io-client as dependency

view details

push time in 7 days

PR merged gatsbyjs/gatsby

fix(gatsby): add explicit dependency on `socket.io-client` and explicitly set `url-loader` fallback status: needs core review

Description

After upgrading to latest, I have begun to have issues with url-loader being able to resolve file-loader, and .cache/app.js being able to resolve socket.io-client. This is likely because I am using pnpm in my particular repository.

url-loader uses a fallback of file-loader, but it only provides a simple string. url-loader also doesn't provide file-loader as a production dependency, nor does it list it as a peer dependency, so it would need to get it from somewhere else.

I'm not sure why this only started breaking now, but this is the error I get:

 ERROR #98123  WEBPACK

Generating JavaScript bundles failed

Cannot find module 'file-loader'
Require stack:
- <require stack leading to url-loader>

File: /path/to/node_modules/typeface-poppins/files/poppins-latin-600.woff

What I've done here is simply resolved that to a fully qualified path, relative to Gatsby.

Additionally, I have added an alias for socket.io-client, because .cache/app.js now imports it, but Webpack cannot find it because the project I am working on doesn't have it installed in its dependencies. That's to fix this error:

 ERROR #98124  WEBPACK

Generating development JavaScript bundle failed

Can't resolve 'socket.io-client' in '/path/to/project/.cache'

If you're trying to use a package make sure that 'socket.io-client' is installed. If you're trying to use a local file make sure that the path is correct.

File: .cache/app.js

Both of these fixes work great in my testing. The only thing I can't be sure of is if the fallback for url-loader will have unintended side effects.

Additionally, because socket.io-client is used directly by Gatsby, it should be installed as a production dependency. If not, then yarn 2 will break, because it won't be able to retrieve it from socket.io.

+5 -0

1 comment

3 changed files

Js-Brecht

pr closed time in 7 days

Pull request review commentgatsbyjs/gatsby

chore(gatsby): Migrate reducers/index to TypeScript

 import { IGatsbyState, ActionsUnion } from "../types" -export const lastAction = (-  _state: IGatsbyState["lastAction"],+export const lastActionReducer = (+  _state: unknown,

Why change to unknown here?

alisson-suzigan

comment created time in 7 days

pull request commentgatsbyjs/gatsby

Widens the check pattern

Just a note - there are some deps declaration already being added in https://github.com/gatsbyjs/gatsby/pull/24465 (PR mentions pnpm but those should be applicable for Yarn PnP as well)

arcanis

comment created time in 7 days

push eventpieh/gatsby

Pranjal Jately

commit sha e86e7d7fed423f13c1b4201f1b092d869bd2bbe3

Replace anonymous function with named function in gatsby-starter-hello-world (#24342)

view details

nikoladev

commit sha 9f76842d6c2594409d934b9c0092752c94135144

remove vulnerable http-proxy version from lockfile (#24344)

view details

Muescha

commit sha 4a47bf601284e8cbf710b08f15c60329fa65adb0

fix(docs): remove double words (#24348)

view details

Muescha

commit sha 44cbb14010b36a3bbe41b437314b0a1624b0b6a8

fix(docs): brand name Webpack to webpack (#22906)

view details

Pedro Filipe

commit sha 0da2f017093e399f54e5304e21486c30d6767cef

feat(recipes): add recipe for Gitlab CI/CD (#24275) * feat(recipes): add recipe for Gitlab CI/CD * fix(recipes): fix typo

view details

Laura Chan

commit sha 76d607c02fe7ce2976885fd756024f5beacb7225

docs: Update documentation links (#24323)

view details

John Otander

commit sha ac86cbe5bf8fa38777b6cd7d5e6404d4bd47693e

fix(gatsby-recipes): Remove import-jsx, use built cli (#24354) Fixes https://github.com/gatsbyjs/gatsby/issues/22991#issuecomment-632713137

view details

John Otander

commit sha ea88112e8da59102e2f2bc7aaa807fa73045e0ad

fix(gatsby-recipes): Add explicit dependencies (#24355) Follow up for #24354

view details

Michelle Gienow

commit sha 7c5d311de7bdcfbe54986ae08fba9f1c70c1c085

Blog gatsby turns 5 (#24357) * add Happy Birthday Gatsby blog * add Gatsby math :) * chore: format * Escape special char in frontmatter * *un* escape special char in frontmatter * Update docs/blog/2020-05-22-happy-fifth-bday-gatsby/index.md Co-authored-by: Ashley McClelland <ashumz@github.com> * Update docs/blog/2020-05-22-happy-fifth-bday-gatsby/index.md Co-authored-by: Ashley McClelland <ashumz@github.com> * Add Gatsby Days CTA Co-authored-by: gatsbybot <mathews.kyle+gatsbybot@gmail.com> Co-authored-by: Ashley McClelland <ashumz@github.com>

view details

Stephen Weiss

commit sha ba5d7287f50cf012e5a8675eeab51272aaa8f71c

docs: debugging html build (#23443) * docs: debugging html build Was trying to understand this issue (when I came across it myself). Ended up finding that using only `import` mattered _even when `gatsby-ssr` was consistently common js_. https://github.com/stephencweiss/stephencharlesweiss.com/pull/352/commits/1c6e4463947e35b59776e32f240eeef0bf54511a * docs: clarify html builds Co-authored-by: Obinna Ekwuno <obinnacodes@gmail.com> * style: linting * Update debugging-html-builds.md Co-authored-by: Obinna Ekwuno <obinnacodes@gmail.com> Co-authored-by: Aisha Blake <aisha@gatsbyjs.com>

view details

Nat Alison

commit sha 40ce451a4355cff2b8be24a2ce61168a2c88b993

perf(www) Only source gatsby core instead of the whole packages directory (#24330) * Only source gatsby-core instead of the whole packages directory * whoops * better checking on mdx transformer * better checking on mdx transformer

view details

Michal Piechowiak

commit sha 44d4d6becc32b4af32a9649c211439f7da0d12a8

chore: fix lint (#24379)

view details

Sidhartha Chatterjee

commit sha 5389bfd7bae3108590e97ac8d69876d8d6623fd5

fix(gatsby): Pass through ws in proxy (#24352) * Pass through ws in proxy * Add handler for socket.io client

view details

Michal Piechowiak

commit sha 99351a42d49bcbf1f6f6029767d98bbf2038d043

revert ws changes (was fixed in master)

view details

Michal Piechowiak

commit sha 84aa7e1f051573eea876bc8cba4e08a8bc72abde

Merge remote-tracking branch 'origin/master' into wip-query-webpack-modules-and-static-queries

view details

Michal Piechowiak

commit sha 044750a839e473383683a7b448a98fb2f68f3882

cleanup package.json files

view details

Michal Piechowiak

commit sha 9d509da3b98aa9e656dfbe0f46090aade1ebb2af

get rid of junk

view details

Michal Piechowiak

commit sha d0997502135c1eadb93fab1b6ce957ab6d944a26

comment out dev/debug logs

view details

push time in 8 days

create barnchgatsbyjs/gatsby

branch : wip-query-webpack-modules-and-static-queries

created branch time in 8 days

push eventgatsbyjs/gatsby

Tomasz Góral

commit sha 08503b2f1397fe4cf6e0c859b9526546aef02a75

fix(gatsby-remark-images-contentful): use `url` for cache key instead of `fileName` (#24338) Co-authored-by: gatsbybot <mathews.kyle+gatsbybot@gmail.com>

view details

push time in 8 days

PR merged gatsbyjs/gatsby

fix(gatsby-remark-images-contentful): use `url` for cache key instead of `fileName` topic: Contentful

Description

Cache logic inside gatsby-remark-images-contentful is based on file name, so there is no chance to have images with same name.

Related Issues

Fixes https://github.com/gatsbyjs/gatsby/issues/23762

+1 -1

0 comment

1 changed file

jagoral

pr closed time in 8 days

issue closedgatsbyjs/gatsby

gatsby-remark-images-contentful exposes same image to render when they should be different

Description

When rendering content through gatsby-plugin-mdx with the gatsby-remark-images-contentful plugin, I am seeing the same image being rendered for all images in the content instead of different ones. I have narrowed this down to the image assets in Contentful images having the same file name (image.png in my case). This results in the cacheKey generated by the plugin to be the same for all images served from Contentful with that filename, even if they are separate assets with unique ID's in Contentful.

This seems like it's a bug, as Contentful and Gatsby are separate and the former is often maintained by editors not knowing that having two image assets with the same file name might cause issues for the website. Nor should they need to care, or am I not

Steps to reproduce

Option 1 is to clone https://github.com/jkarsrud/remark-contentful-image-repro and run it in a browser to observe the bug. Replacing one of the image URL with the following in /src/posts/test.md will show that the file name matters; //images.ctfassets.net/wgbykpk4lo2v/1PxG4IVt7p8Y3uWG8uQgEz/bd8084807826e28d92738b147c59fd1e/andrew-neel-cckf4TsHAuw-unsplash.jpg

Option 2 is to create your own version of the repo above.

Create a Gatsby site with gatsby-plugin-mdx and gatsby-remark-images-contentful. Then, create a post with the following content (Note: The images here are hosted on my personal Contentful space):

![Image 1](//images.ctfassets.net/wgbykpk4lo2v/1xMx6pMioceAkPLHq4SSIE/896966d66f01337171a39400e71bb75d/image.png)

![Image 2](//images.ctfassets.net/wgbykpk4lo2v/20HBreTyDleLCOTBuoSh9F/b440c073102b1f61a9fef3585631e960/image.png)

Then make a page template with the following content:

import React from "react"
import { graphql } from "gatsby"
import { MDXProvider } from "@mdx-js/react"
import { MDXRenderer } from "gatsby-plugin-mdx"

const IndexPage = ({ data }) => {
  return (
    <MDXProvider>
      <div style={{ margin: "0 auto", maxWidth: 1000, padding: 10 }}>
        <MDXRenderer>{data.post.body}</MDXRenderer>
      </div>
    </MDXProvider>
  )
};

export const query = graphql`
  query IndexQuery {
    post: mdx {
      body
    }
  }
`;

export default IndexPage;

Expected result

The images in the content rendered from Markdown should be different, even if the filename is the same

Actual result

The images rendered from the Markdown content are the same image.

Environment

  System:
    OS: macOS High Sierra 10.13.6
    CPU: (8) x64 Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 12.16.3 - ~/.volta/tools/image/node/12.16.3/6.14.4/bin/node
    Yarn: 1.21.1 - ~/.volta/tools/image/yarn/1.21.1/bin/yarn
    npm: 6.14.4 - ~/.volta/tools/image/node/12.16.3/6.14.4/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 81.0.4044.129
    Firefox: 70.0.1
    Safari: 13.1
  npmPackages:
    gatsby: ^2.21.0 => 2.21.0 
    gatsby-plugin-mdx: ^1.2.5 => 1.2.5 
    gatsby-plugin-sharp: ^2.6.0 => 2.6.0 
    gatsby-remark-images-contentful: ^2.3.0 => 2.3.0 
    gatsby-source-filesystem: ^2.3.0 => 2.3.0 

closed time in 8 days

jkarsrud

issue commentgatsbyjs/gatsby

contextModified is not properly re-evaluated if pages are deleted & created

You are right. I just wonder how we could fix that... deletePage has immediate effect so our store removes that completely and when we recreate it, there's nothing to compare.

I do wonder if we could figure out "entry" createPage action call to grab oldPage from it, run all of the onCreatePage cascade and then compare after everything finished.

xavivars

comment created time in 8 days

push eventpieh/gatsby

Michal Piechowiak

commit sha 67e2d306f334a38dac7a8e9580e465636738987f

moar stuff

view details

push time in 8 days

pull request commentgatsbyjs/gatsby

New, shorter syntax for fragment. Replaced anonymous function with na…

It has been over 24 hours but the Cloud Tests are still waiting for the status to be reported. Any particular reason why this could be?

Likely a fluke, but those tests aren't impacted by starter changes, so you should not worry about them

pranjaljately

comment created time in 8 days

push eventgatsbyjs/gatsby

Sidhartha Chatterjee

commit sha 5389bfd7bae3108590e97ac8d69876d8d6623fd5

fix(gatsby): Pass through ws in proxy (#24352) * Pass through ws in proxy * Add handler for socket.io client

view details

push time in 8 days

PR merged gatsbyjs/gatsby

fix(gatsby): Pass through ws in proxy

Currently ws doesn't work for our websocket-manager (which we use to emit updates) because the newly added develop proxy server doesn't handles upgrades or pass through ws messages.

Data updates work nonetheless because socket.io gracefully downgrades to polling but that is not ideal.

This fixes that.

+5 -0

1 comment

1 changed file

sidharthachatterjee

pr closed time in 8 days

Pull request review commentgatsbyjs/gatsby

fix(data-dependency-tracking): clear data dependencies when rerunning dirty queries

 const popNodeQueries = state => {      return dirtyIds   }, new Set())++  // boundActionCreators.deleteComponentsDependencies([...uniqDirties])

Check https://circleci.com/gh/gatsbyjs/gatsby/418102?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link for example of failed test before fix was applied

pieh

comment created time in 8 days

pull request commentgatsbyjs/gatsby

fix(gatsby): remove default noscript tag from html.js template

@nkhil This changes was added in gatsby@2.18.11. You can either upgrade or use guide in https://www.gatsbyjs.org/docs/custom-html/ to customize html template

gilbertoayala12

comment created time in 9 days

push eventgatsbyjs/gatsby

Michal Piechowiak

commit sha fc25befd9c52741400066ef82e2112564ca8136a

fix(data-tracking): clear data dependencies on dirty queries

view details

push time in 10 days

push eventgatsbyjs/gatsby

Michal Piechowiak

commit sha 44d4d6becc32b4af32a9649c211439f7da0d12a8

chore: fix lint (#24379)

view details

push time in 10 days

PR merged gatsbyjs/gatsby

chore: fix lint status: triage needed

<!-- Have any questions? Check out the contributing docs at https://gatsby.dev/contribute, or ask in this Pull Request and a Gatsby maintainer will be happy to help :) -->

<!-- Is this a blog post? Check out the docs at https://www.gatsbyjs.org/contributing/blog-contributions/, and please mention if the blog post is pre-approved by someone from Gatsby. -->

Description

<!-- Write a brief description of the changes introduced by this PR -->

Documentation

<!-- Where is this feature or API documented?

  • If docs exist:
    • Update any references, if relevant. This includes Guides and Gatsby Internals docs.
  • If no docs exist:
    • Create a stub for documentation including bullet points for how to use the feature, code snippets (including from happy path tests), etc.
  • Tag @gatsbyjs/learning for review, pairing, polishing of the documentation -->

Related Issues

<!-- Link to the issue that is fixed by this PR (if there is one) e.g. Fixes #1234

Link to an issue that is partially addressed by this PR (if there are any) e.g. Addresses #1234

Link to related issues (if there are any) e.g. Related to #1234 -->

+1 -1

0 comment

1 changed file

pieh

pr closed time in 10 days

Pull request review commentgatsbyjs/gatsby

fix(data-dependency-tracking): clear data dependencies when rerunning dirty queries

 const popNodeQueries = state => {      return dirtyIds   }, new Set())++  // boundActionCreators.deleteComponentsDependencies([...uniqDirties])

next commit that isn't linting fix that is 😅

pieh

comment created time in 10 days

more