When I create pages using createPages and then access them directly, the necessary chunks are not resolved properly on production scenario.
Reproducible build: https://next--microlink.netlify.com/
Source Code: https://github.com/microlinkhq/www/blob/next
I followed the tutorial for programatically create page from data, where basically:
I'm getting the expected result on development, but on production, something not expected is happening.
If I enter at / and navigate until the createPage generated, all is fine.
https://next--microlink.netlify.com/ to → https://next--microlink.netlify.com/docs/sdk/getting-started/overview

However, if I access to the route created by createPage directly, it doesn't work:
https://next--microlink.netlify.com/docs/sdk/getting-started/overview

System:
OS: macOS 10.14.4
CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
Shell: 5.3 - /bin/zsh
Binaries:
Node: 8.15.1 - /usr/local/bin/node
npm: 6.4.1 - /usr/local/bin/npm
Languages:
Python: 2.7.16 - /usr/local/bin/python
Browsers:
Chrome: 73.0.3683.103
Firefox: 66.0.3
Safari: 12.1
npmPackages:
gatsby: ~2.3.25 => 2.3.25
gatsby-plugin-canonical-urls: ~2.0.12 => 2.0.12
gatsby-plugin-catch-links: ~2.0.13 => 2.0.13
gatsby-plugin-create-client-paths: ~2.0.5 => 2.0.5
gatsby-plugin-google-analytics: ~2.0.18 => 2.0.18
gatsby-plugin-meta-redirect: ~1.1.1 => 1.1.1
gatsby-plugin-netlify: ~2.0.14 => 2.0.14
gatsby-plugin-react-helmet: ~3.0.12 => 3.0.12
gatsby-plugin-remove-trailing-slashes: ~2.0.10 => 2.0.10
gatsby-plugin-sass: ~2.0.11 => 2.0.11
gatsby-plugin-sitemap: ~2.0.12 => 2.0.12
gatsby-plugin-styled-components: ~3.0.7 => 3.0.7
gatsby-redirect-from: ~0.1.1 => 0.1.1
gatsby-source-filesystem: ~2.0.29 => 2.0.29
gatsby-transformer-javascript-frontmatter: ~2.0.10 => 2.0.10
gatsby-transformer-json: ~2.1.11 => 2.1.11
gatsby-transformer-remark: ~2.3.8 => 2.3.8
gatsby-transformer-yaml: ~2.1.11 => 2.1.11
npmGlobalPackages:
gatsby-cli: 2.4.8
Do you create the page with or without a trailing slash?
with the slug, but gatsby-plugin-remove-trailing-slashes is loaded as welll.
I tried to remove the plugin but the result is the same.
Can you try reproducing this on a separate site? It's hard to know what's going on with a complex site we don't understand. https://gatsby.dev/reproduction
I understand that my project could be a bit big as a first impression, but it is not, in fact, it has all the things necessaries for reproducing the problem.
I'm trying to identify what is causing the problem, isolating the plugin or whatever is causing it but it's hard and tedious since you need to regenerate the production build every time, disabling/enabling things.
I think it could be related with #11524 but not sure yet, need to continue debugging it
@KyleAMathews It looks like the site documenting how to create a reproduction doesn't work.
@dja do you have something redirecting .dev domains?
The non-redirected URL is https://www.gatsbyjs.org/contributing/how-to-make-a-reproducible-test-case/
Fixed ma problem: https://github.com/microlinkhq/www/commit/ebd5c8f9e0ae011415095e7ceb0f5ac27cad462b
I have a webpack alias over the src folder to be easy import any component, like import { Svg } from 'components/elements'
I rebuild the code many times, mainly for identifying what is introducing the error and generate the specific reproducible case.
I took me until src/helpers/hoc/with-slug.js where I'm doing a { Svg } from 'components/elements'
Not sure why but I referenced there the real path instead of the alias and now it is working as expected.
I close the issue since the error is fixed and it's not a gatsby thing, but probably something is happening under the hood that is not clear and a build error or more clear error could be better.
🤔
Most helpful comment
@dja do you have something redirecting .dev domains?
The non-redirected URL is https://www.gatsbyjs.org/contributing/how-to-make-a-reproducible-test-case/