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

fix(gatsby): character escape sequences in regex filter in graphql queries #26592

Merged
merged 1 commit into from
Feb 24, 2021

Conversation

stefanprobst
Copy link
Contributor

Description

attempt to fix character escape sequences in regex filters, i.e. queries like:

export const query = graphql`
{
  allFile(filter: {base: {regex: "/\\w+\\.PNG$/i"}}) {
    nodes { base }
  }
}
`

this is a follow-up to #25047 which was closed prematurely.

  • removes the backslash replaceing from utils/prepare-regex.ts which is not needed (any more? might have been before the switch away from relay)
  • removes comment about double-escaping from the docs
  • in tests, double-escaping is necessary when query is inline (see e.g. this test here). i have added two query tests in this pr to illustrate this (double-escaping when query defined inline, normal escaping when read via fs.readFile). these are not strictly necessary and could be removed
  • with these changes, queries with escape sequences will still break. this is an issue with eslint-plugin-graphql which gatsby uses - throws with "Syntax Error: Invalid character escape sequence`. disabling the plugin here makes things work. i have opened fix: support character escape sequences in template literal apollographql/eslint-plugin-graphql#282 upstream

Related Issues

#25047

@gatsbot gatsbot bot added the status: triage needed Issue or pull request that need to be triaged and assigned to a reviewer label Aug 22, 2020
Copy link
Contributor

@pvdz pvdz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm. Thank you.

Regexes are relatively slow and shouldn't be used if performance is a concern. But oh well, if people want to, they should be able to.

// Double escaping is needed to get past the GraphQL parser,
// but single escaping is needed for the RegExp constructor,
// i.e. `"\\\\w+"` for `/\w+/`.
.replace(/\\\\/, `\\`),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC this was the actual problem, this regex was missing a global flag?

But I mean if we can drop this entirely that's even better. Will ask @vladar to take a sanity check for graphql.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double escaping my regex stops the errors, but doesn't return any results the same way the graphiql explorer does... Completely out of ideas.

@pvdz
Copy link
Contributor

pvdz commented Aug 25, 2020

(What's the reason this is in Draft mode?)

@pvdz pvdz added topic: GraphQL Related to Gatsby's GraphQL layer type: bug An issue or pull request relating to a bug in Gatsby and removed status: triage needed Issue or pull request that need to be triaged and assigned to a reviewer labels Aug 25, 2020
@stefanprobst
Copy link
Contributor Author

Copy link
Contributor

@vladar vladar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some context: escaping was added in #11002 and fixed #10989 and #9944

The change makes sense to me but it is potentially a breaking change. For example, take a blog starter with this query:

{
  allFile(filter:{relativePath: { regex: "/\\\\.png/" }}) {
    nodes {
      relativePath
    }
  }
}

Before this PR it returns a list with a single file. After this PR it returns an empty list (which is what you would expect but it is still a breaking change).

I think we should definitely merge this but maybe as a part of the next major?

@vladar vladar added the breaking change If implemented, this proposed work would break functionality for older versions of Gatsby label Aug 25, 2020
@pvdz pvdz changed the title fix: character escape sequences in regex filter in graphql queries Aug 25, 2020
@stefanprobst
Copy link
Contributor Author

the change makes sense to me but it is potentially a breaking change.
I think we should definitely merge this but maybe as a part of the next major?

yes, makes sense.

however, until then we probably should:

  • add a global flag to the replace regex here. your example query would currently break with something like regex: "/\\\\w+\\\\.PNG$/i"
  • mention here the current double escaping necessity (similar to how it's mentioned here)

sidenote: i believe the original fix in #11002 was just a workaround for the upstream problem in eslint-plugin-graphql -- the error message in both #10989 and #9944 ("Syntax Error: Invalid character escape sequence: \w. graphql/template-strings") actually comes from eslint-plugin-graphql.

Copy link
Contributor

@vladar vladar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's get this merged 🚢

@vladar vladar merged commit 9ecec6c into gatsbyjs:master Feb 24, 2021
@stefanprobst
Copy link
Contributor Author

  • with these changes, queries with escape sequences will still break. this is an issue with eslint-plugin-graphql which gatsby uses - throws with "Syntax Error: Invalid character escape sequence`. disabling the plugin here makes things work. i have opened apollographql/eslint-plugin-graphql#282 upstream

hi - can't remember the exact details - but just a heads up that the upstream issue which this pr depended on is still open (and hasn't received any comments). but maybe it's not necessary anymore?

@stefanprobst stefanprobst deleted the fix/regex-filter branch February 24, 2021 11:12
@vladar
Copy link
Contributor

vladar commented Feb 24, 2021

Thanks for the heads up. I will test this scenario with our latest changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change If implemented, this proposed work would break functionality for older versions of Gatsby topic: GraphQL Related to Gatsby's GraphQL layer type: bug An issue or pull request relating to a bug in Gatsby
4 participants