I find this pattern type MultiversalAppBootstrapProps<PP extends MultiversalPageProps = MultiversalPageProps> in some generic types but i dont whats mean... if PP extends MultiversalPageProps asign the value passes as MultiversalPagePros as default value?? Thanks

I just discovered https://github.com/romefrontend/rome and it looks very promising.

I have no idea how it can work with Next.js.

I'm concerned about how it could be breaking with webpack. But interested about how it could replace eslint and prettier (we don't use prettier, mostly because of prettier/prettier#6644). I like the idea of having one tool to deal with all those boring things, as long as it does the job well.

Also, it would require to convert the whole project from "2 spaces" to tabs. But this is better for developer accessibility anyway.

The plan is to see how it can work with Next and see if it can be integrated within NRN then.

Rome is built by Facebook and Babel, according to https://www.infoq.com/news/2020/03/rome-experimental-js-toolchain/

Discussion opened on Next.js community: vercel/next.js#16754

Hi,

I'm wondering if it's possible to make the default entrypoint / be in the default language, rather than force us to a subroute for that 1 language only?

Maybe this is best implemented in https://github.com/UnlyEd/next-right-now/tree/gh-pages/guides/i18n as a guide.

This thread is meant for the community to share their feedback regarding the built-in third party tools.

Feel free to give your feedback regarding the third-parties used by this boilerplate.

Please use the following template. Also, if you really liked or didn't liked something, please explain why, as it'll help us to do better!

Template:

**About GraphCMS** (GraphQL Server + CMS + Database):
- [ ] I knew about it
- [ ] I had already used it
- [ ] I used it for the first time with NRN
- [ ] I like it and I'm glad you used it
- [ ] I plan on using it again in the future
- I wish you had used those alternatives instead: 

**About Locize** (I18n, with in-editor context):
- [ ] I knew about it
- [ ] I had already used it
- [ ] I used it for the first time with NRN
- [ ] I like it and I'm glad you used it
- [ ] I plan on using it again in the future
- I wish you had used those alternatives instead: 

**About Sentry** (Monitoring and alerting):
- [ ] I knew about it
- [ ] I had already used it
- [ ] I used it for the first time with NRN
- [ ] I like it and I'm glad you used it
- [ ] I plan on using it again in the future
- I wish you had used those alternatives instead: 

**About Zeit** (Serverless, deployments, infrastructure):
- [ ] I knew about it
- [ ] I had already used it
- [ ] I used it for the first time with NRN
- [ ] I like it and I'm glad you used it
- [ ] I plan on using it again in the future
- I wish you had used those alternatives instead: 

**About Next.js** (Isomorphic framework for react):
- [ ] I knew about it
- [ ] I had already used it
- [ ] I used it for the first time with NRN
- [ ] I like it and I'm glad you used it
- [ ] I plan on using it again in the future
- I wish you had used those alternatives instead: 

**About Amplitude** (CSS-in-JS):
- [ ] I knew about it
- [ ] I had already used it
- [ ] I used it for the first time with NRN
- [ ] I like it and I'm glad you used it
- [ ] I plan on using it again in the future
- I wish you had used those alternatives instead: 

**About Bootstrap/Reactstrap** (UI components library):
- [ ] I knew about it
- [ ] I had already used it
- [ ] I used it for the first time with NRN
- [ ] I like it and I'm glad you used it
- [ ] I plan on using it again in the future
- I wish you had used those alternatives instead: 

**About Cypress** (End-to-end testing):
- [ ] I knew about it
- [ ] I had already used it
- [ ] I used it for the first time with NRN
- [ ] I like it and I'm glad you used it
- [ ] I plan on using it again in the future
- I wish you had used those alternatives instead: 

**Additional notes**: (optional)

Thanks for sharing!

I'm getting an error when building the up locally, everything is fine on vercel though.

|> Build error occurred Error: Export encountered errors on following paths
     Error: Network error: Only absolute URLs are supported

Steps to reproduce:

• yarn build

Results:

Did this happen because I used npm instead of yarn?

You're preloading fonts with:

<link rel="preload" as="font" href={'/static/fonts/NeuzeitGrotesk/font.css'} />

But I think it should actually be:

<link rel="preload" href="/static/fonts/NeuzeitGrotesk/NeuzeitGrotesk-regular.woff2" as="font" type="font/woff2"> 

https://web.dev/codelab-preload-web-fonts/

Status

PR in progress at #52

Context

@jajourda @samuelcastro I'd like to know what you think about the current demo (e.g: https://nrn-v1-hyb-mst-aptd-gcms-lcz-sty-c1-oylx1iihd.now.sh/fr)

I think we should add more example and restructure those examples (UI/UX)

It's mostly visual, but do you have any idea about how to do it better? Would you like to work on it?

Quick list of stuff we should showcase (IMHO):

• ✅ Use of getStaticProps (SSG)
  • Done in 3 pages
• ✅ Use of getStaticProps with fallback (?)
• ✅ Use of getStaticProps with revalidate (?)
• ✅ Use of getServerSideProps (SSR)
  • Done at /products
• 🏁 Use of getInitialProps (SSR+CSR), should we? I prefer the new getSP/getSSP way, cleaner
• ✅ Use of different locales/lang
  • Done in all pages
• ✅ Use of i18next features
  • Done in the /examples page
• ⚠️ Use of i18nLink (client side navigation with i18n support)
  • Done in all pages, but now shown explicitly in the demo
• ✅ Use of custom 404
• ⚠️ Use of core hooks
  • Done in multiple files/pages, but now shown explicitly in the demo
• ✅ Use of Apollo HOC
  • Done in many pages, both with SSR/SSG (not done with getInitialProps, should we? 🤔)
• ⚠️ Use of graphQL queries
  • Done in many pages, but now shown explicitly in the demo
• ✅ Use of CSR links
  • Done in many pages
• ✅ Use of analytics (Amplitude)
  • Done in all pages, demo at /examples
• ✅ Use of monitoring (Sentry)
  • Done in all pages, demo at /examples
• ✅ Use of API
  • Demo at / with /api/status
• ✅ 500 top-level error (would display native 500 error page I guess)
• ✅ 500 page error (would display page with DefaultErrorLayout)
• ✅ 404 page (no obvious example, but easy to reproduce, unlike 500 errors)

Is there anything important we're missing?

Status

Community is free to contribute, we won't likely have the time to add this feature

Issue

Sentry doesn't have access to source maps, which makes debug harder.

I do not know how to fix that, I believe it had worked at some point in the past, but may have broken due to some dependency update.

Current configuration

https://www.npmjs.com/package/@zeit/next-source-maps is used to generate source maps

It's configured in next.config.js, see https://github.com/UnlyEd/next-right-now/blob/master/next.config.js#L1-L8

There seems to be additional steps to send the files to Sentry, and they're complicated and require some kind of authentication to upload files to their servers. See https://docs.sentry.io/platforms/javascript/sourcemaps/

Also, it should be enabled for NODE_ENV=production only, not during development (to avoid latency due to source files upload, which would completely break DX)

Sentry logs in development (browser)

https://youtu.be/fr3LX5aGiDI

Sentry logs in development (server)

https://youtu.be/tSqi4A1yslI

Sentry logs in production (server)

https://youtu.be/S2o6YibLnvA

Sentry logs in production (browser)

https://youtu.be/kUUO-1Gyujc

Resources:

• See vercel/next.js#8106 (comment) for initial discussion
• vercel/next.js#8873
• https://docs.sentry.io/platforms/javascript/sourcemaps/
• https://docs.sentry.io/cli/configuration/
• https://forum.sentry.io/t/sentry-webpack-plugin-and-next-js-sourcemaps/4153/4 experiments (fedback)
• https://docs.sentry.io/error-reporting/configuration/?platform=javascript we may need to define SENTRY_RELEASE and SENTRY_ENVIRONMENT variables, but I believe we do it already at

  next-right-now/src/utils/sentry.ts

  Lines 12 to 17 in 6afd12d

  	Sentry.init({
  	dsn: process.env.SENTRY_DSN,
  	enabled: process.env.NODE_ENV !== 'test',
  	environment: process.env.APP_STAGE,
  	release: process.env.APP_VERSION_RELEASE,
  	});

• https://stackoverflow.com/questions/61011281/next-js-source-maps-with-typescript-on-sentry SO question about how to avoid "leaving the source map publicly available on the server"

Motivations

Next has recently released a new way to handle env variables.

The migration to .env instead of .env.build would allow to use next dev instead of now dev.

This change may fix the current "Next.js dev server gets stuck after a while, requests just spin" (see vercel/vercel#3612 (comment))

Also, it would allow to run Next in debug mode using NODE_OPTIONS='--inspect' next, which is necessary for VSCode IDE to be able to attach its debug process. (see vercel/next.js#10807)

Also, the recent NEXT_PUBLIC_ env variables is meant to make it more obvious what ENV vars are shared with the browser, and this would increase transparency and understanding.

Overall, the dev experience may become better.

Concerns

Needs to be compatible with Vercel. No idea what issues might be encountered.

Current:
https://nextjs.org/docs/api-reference/next.config.js/environment-variables

New:

• https://nextjs.org/docs/basic-features/environment-variables

Goal

Run a lighthouse report when a commit is pushed, which eventually displays the lighthouse results as a PR comment.

foo-software/lighthouse-check-action#24

This could run in parallel with E2E (or afterwards, I'm not sure if parallel github actions are possible)

The goal is to replace GraphQL API by Airtable API, for several reasons:

• Showcase how to consume a REST-ish API
• Easier to setup than GraphCMS
• Airtable provides a free plan, and has much higher limitations than GraphCMS for its free plan
  • Requested #16
• Make this the new default preset (simpler, cheaper)

Base preset: v2-mst-aptd-gcms-lcz-sty
New preset name: v2-mst-aptd-at-lcz-sty

Hello! Thank you very much for your work!
It is possible to continue usage of i18next but without locize vendor?
Advise steps for implementation please!

PS: I tried using next-i18next but their configuration uses getInitialProps in _app and this disables static optimization. The developers themselves refuse to change anything in this direction.

Then I found your repository and studied the approaches you proposed!
Thanks for any help and awesome ideas in context of problem solving with latest next.js!

http://err.sh/vercel/vercel/next-legacy-routes-optimized-lambdas

Need to handle stuff related to robots from next.config.js instead of now.json file to avoid opting out from optimized lambdas on Vercel.

Probably doesn't affect SSG.

Hi, I couldn't find a list of presets, is this documented somewhere?

Thanks!

with-graphql-hooks may be an alternative to the current implementation

See https://github.com/vercel/next.js/tree/canary/examples/with-graphql-hooks

Main interest would be to reduce the bundle size (for all pages)

I'll give it a try at some point, if nobody does it first 😉

Just noticed that when merging PR into master, the Github action fails at the step Comment PR (Deployment success) with:

Deployment SUCCESS
	 Commit 5f4b261a979b133804354db7e9aff7a2c199ec6c successfully deployed to https://nrn-customer1-p6ji63wh9.now.sh"
Couldn't find an open pull request for branch with head at 5f4b261a979b133804354db7e9aff7a2c199ec6c.

See https://github.com/UnlyEd/next-right-now/runs/473721578

This is to be expected, as there are indeed no open PR for the comment to be written to.
Maybe the .github/workflows/deploy-zeit-production.yml file should be updated so that it doesn't try to write a comment upon success? This way, it will pass (be "green") instead of this false-positive failure. Real errors would still be caught on master.

What do you think @Demmonius?

I'm trying to use i18nextInstance from StaticPropsOutput on SSG/getStaticProps:

const commonStaticProps: StaticPropsOutput = await getCommonStaticProps(props);

console.log(commonStaticProps.props.i18nextInstance); // undefined

But it's undefined for some reason.

I'd like preset branches to be treated as production branches.

For example, pushing to https://github.com/UnlyEd/next-right-now/tree/v2-mst-aptd-gcms-lcz-sty would trigger a Vercel production deployment.

This would help enforce any work should be done under a different branch, and then merged into preset branch(es).

This way, each branch preset would automatically use a production deployment.
Any other branch would be treated as staging.

Also, I have a few concerns regarding projects created using NRN. I wouldn't want the default configuration to deploy to production when using our internal naming, that could be harmful.

So, ideally, I'd want to enforce that NRN-specific rules can only be triggered on NRN.

I don't know if it's technically possible and I've opened a question at https://github.community/t/is-it-possible-to-conditionally-run-an-action-based-on-the-repo-name-url/116115

With the recent release of v9.5, I intend to migrate both main presets (v2-x) to the latest v9.5.2 version.

Also, I'll remove the routing from now.*.json files to add it directly into next.config.js instead.
This will help solve #130 and should improve lambda performances. (for SSR, mostly)

E.g:

  "routes": [
    {
      "src": "/robots.txt",
      "dest": "/robots/!production.txt"
    }
  ],

It should also fix a bug regarding client side transition to 404 pages, see #142.

There shouldn't be any regression of any sort. I expect a smooth upgrade.

To do list:

• Migrate to v9.5.2
• Move routing to next.config.js - See https://nextjs.org/blog/next-9-5#support-for-rewrites-redirects-and-headers
• Add new script to build with profiler in production (make it obvious it's a possibility so that devs can learn more about it) - See https://nextjs.org/blog/next-9-5#production-react-profiling
• Add example to see catch-all in action - See https://nextjs.org/blog/next-9-5#optional-catch-all-routes

Hi.
For correct handle query params passed to dynamic route, you need to specify as and href in full object format instead of string format.
See that issue: vercel/next.js#10494 (comment)

How to do this with our I18nLink?
I'm a little surprised that I don't have this opportunity right now.

I'm getting Internal Server Error when I don't define SENTRY_DSN on .env.local.

It should be optional.

If I have site.com/en/catalog/5?brand=2page if I use i18nRedirect to fr language
instead of site.com/fr/catalog/5?brand=2
i go to site.com/fr/catalog/[id]?brand=1&id=6

Dynamic url structure for this page is [locale]/catalog/[id] with query parameter brand passed with Link;

Since v9.4.4, type inference is natively supported by Next.js

See vercel/next.js#11842

The main advantage is that it doesn't require to manually write props for pages, but those would be inferred from the return value of getStaticProps or getServerSideProps.

See #14 (comment)

Basically improve existing i18n doc by explaining how i18n things are linked together

PR welcome

If you go to the examples with JS disabled, the main body shows, but not the header:

https://nrn-customer2.now.sh/

This is arguably fine as the header is only for developer information. However, other parts also don't work such as the Examples link, and once on the examples page (by manually entering the address) you are greeted by:

Which is clearly not correctly server-side rendered.

Hello!

I am trying to dip my toe into NextJS and I tend to search for templates to see what "best" practices are out there for a certain framework I am interested in.

This is definitely one of the most fully featured, production-ready templates, but it has definitely been hard to rip out things I don't need and get started fresh so I can actually develop my own app.

I don't find the "plugin" system that highly customizable since "plugins" seem to already be bundled into the 2 main templates you offer, and I have been having hard time trying to rip things out that I don't need (i18n/locize, example app, MST tenancy (although looks like I can opt out by not using certain now json files), and etc.). I was hoping the system would be more pick-and-choose-y.

Did I miss some documentation on these steps? Any guidance on this would be helpful!

I just did things to get started for this.

but i got this message

IWAZ@JINKYU MINGW64 ~/Desktop/my-project/react-blog-2020_NRN (master)
$ yarn start
yarn run v1.22.4
$ now dev --listen 8888
> UPDATE AVAILABLE Run `yarn add now@latest` to install Now CLI 19.0.1
> Changelog: https://github.com/zeit/now/releases/tag/[email protected]
> Now CLI 16.7.3 dev (beta) — https://zeit.co/feedback
> Creating initial build
The system cannot find the path specified.
child_process.js:122
  p.open(fd);
    ^

Error: EBADF: bad file descriptor, uv_pipe_open
    at Object._forkChild (child_process.js:122:5)
    at setupChildProcessIpcChannel (internal/bootstrap/pre_execution.js:338:30)
    at prepareMainThreadExecution (internal/bootstrap/pre_execution.js:54:3)
    at internal/main/run_main_module.js:7:1 {
  errno: -4083,
  code: 'EBADF',
  syscall: 'uv_pipe_open'
}
Done in 24.83s.

when i installed this on my Mac laptop, it worked well.

it's a really shame that i can't run this on my window laptop.

When deployed in eu-central-1, GraphCMS returns an HTTP 400 if the authorization header is set without the Bearer prefix.

The sample application uses api-euwest which still accepts an authorization header set directly.

I provided a fix with the pull request 39.

Are you planning to implement any security check on preview mode, like: https://nextjs.org/docs/advanced-features/preview-mode#securely-accessing-it-from-your-headless-cms

I was looking to see how GraphCMS handles it but couldn't find much, just https://docs.graphcms.com/docs/guides/preview-environment-flow.

Context

I'd love to have a CodeSandbox template available, it would be great for a few use-cases:

• Allowing newcomers to test stuff on CodeSandbox without having to install anything locally
• Provide a CodeSandbox link when reporting issues to other 3rd parties (like Next, etc.)

Status

WIP, unstable

I've tried to do it, but ran into a few unexpected issues.

CodeSandbox issue: codesandbox/codesandbox-client#4230
CodeSandbox template: https://codesandbox.io/s/nrn-v1-hyb-mst-aptd-gcms-lcz-sty-56qrj?file=/README.md

Also, it may be interesting to configure the CodeSandbox default behaviour through sandbox.config.json, see https://codesandbox.io/docs/configuration

Happens on:

• https://nrn-v2-mst-aptd-gcms-lcz-sty-c1.now.sh/en/examples/built-in-utilities/i18nLink-component
• https://nrn-v2-mst-aptd-gcms-lcz-sty-c1.now.sh/en/examples/built-in-utilities/errors-handling

Uncaught SyntaxError: Unexpected token '<' is thrown because a 404 page is returned by the client when trying to navigate.

This is due to the link going to the wrong page, but need to take a closer look as to why it doesn't go to the expected page.

I want to list a few things that can improve performance even more:

Next Optimized Images: To optimize image load.
Babel Import Graphql: Babel plugin to enable import syntax for .graphql and .gql files.
Babel Plugin Graphql Tag: Reduces the script initialization time and removes the graphql-tag dependency

Thoughts?

It'd be great to use graphql-config with graphql-cli to take advantage of the code generation for type schemas through package.json scripts rather than using IDEs config (webstorm/vscode/etc), this would improve the development workflow quite a lot.

Also, I'm having a hard time trying to integrate graph-config on vscode, since they're released a brand new version recently I can't find a vscode extension that properly works with it, having a script to generate the schema and types would be super helpful.

stephen/vscode-graphql#27
kamilkisiela/graphql-config#555
Urigo/graphql-cli#1249

We could do something like:

schema: 
  - https://graphcms-url:
      headers:
        Authorization: key
extensions:
  codegen:
    generates:
      ./schema.graphql:
        plugins:
          - schema-ast
        config:
          commentDescriptions: true
      ./src/common/types/data/DataTypes.tsx:
        plugins:
          - typescript
          - typescript-operations

and then

"scripts": {
   "codegen": "npx graphql-codegen"
}

With this in place we won't need to maintain our own types (GraphCMS) since everything will be pulled out directly from the source. (Single Source of Truth)

Also we need to migrate the .graphqlconfig file to the new graphql-config structure.

This is just to document and track the issue described on this issue: GoogleChrome/lighthouse#10876

I think it'd be really helpful to show up some simple authentication workflow, maybe using Auth0 or Firebase Auth or even AWS Cognito. Just to illustrate how one would handle cookies coming from the server, specially with the server/bowser reconciliation in the context of a SSR/SSG.

What do you think.

Hey @Vadorequest does this have support for locale subpaths? Like https://github.com/isaachinman/next-i18next#5-locale-subpaths.

Thanks!

Context

This boilerplate has been built based on a real professional use-case.

This use case relies on the following built-in 3rd parties:

• Monitoring (Sentry 3rd party, large freemium)
• Analytics (Amplitude 3rd party, large freemium)
• GraphQL API (GraphCMS 3rd party, small freemium)
• I18n (Locize 3rd party, 2w free trial, not free)
• Hosting (Zeit 3rd party, large freemium, no pay-or-leave)

Also, it features the following built-in design choices:

• SSR (no SSG nor static optimization are possible without altering the boilerplate in a non-straightforward way)
• Multi-tenants/monorepo (not single-tenant friendly without altering the boilerplate in a non-straightforward way)

Legend:
Freemium means free with "more or less" limited capabilities on free plan.

• Small means the free plan is considered too limited for most real use cases
• Large means the free plan is limited but large enough to cover non enterprise-grade needs

Concerns

There are 2 main concerns at hand.

It's too complicated/opinionated

Opinions can be good, I personally don't regret those 3rd party choices. But not everyone like them, not everyone need them either. They are currently built-in, but it would be better to have them opt-in and let people easily choose what boilerplate preset fits their need the most closely.

It's not free

Locize provides a free trial, but it's just a trial and it's not free. Thus, it's a strong issue for associations and organisation that don't have any funds, or can't afford it.

GraphCMS free plan is limited to 500 records, which can be considered "good enough" or "far too little" depending on the use cases.

Needs

• Quickly understanding which boilerplate to use based on my current requirements
• Quickly clone the boilerplate I want to use (git clone specific branch)
• Quickly see what changes have been applied to add/remove a feature compared to another preset
• Ability to apply identical updates to multiple presets easily (ease to maintain all those presets by reducing issues when applying changes that are common to all, such as dependency updates, security updates, good practices, etc.)

Solution

I believe the best way to keep the current advanced/opinionated boilerplate while allowing for simpler/faster re-use is to create "presets" from the initial boilerplate. A preset could be considered as similar to a fork, but lives within the same repository.

After much thinking on the matter, I've come to the following requirements:

• A preset should live within a git branch.
  • Each of those branch will have its own "preset origin" from where it got "forked".
  • Those branch must not be confused with working branches, it must be obvious they are official, stable presets where anyone can get started from.
• Each preset should specify whether it is using SSR or SSG design
• Each preset should specify whether it is using multi-tenants or single-tenant design
• Each preset should specify which 3rd parties or features have been removed (compared to the most complex preset, which currently lives in the master branch)
• This boilerplate will likely evolve in the future, maybe more features or 3rd parties will be added/removed/changed. It should be made easy to create major versions of the presets, based on a different base major preset.
• Each preset must be documented in the main README.md file, and explained thoroughly. A link to the branch and to the PR must be present (against its "preset origin" so that only minimal changes are shown in the diff), also a git clone command must be present to allow for quick local clone of a preset
• A PR can be created (but closed to avoid false-positive PR) for quick review of source code changes between two presets. It will also allow the community to post comment on the PR source code changes if questions arise and will reduce the github issues created if proper answers are given to those questions, as future readers may also ask themselves the same question and see a proper answer right there.
• A preset cannot contain uppercased letters, as Zeit won't allow to create a project with uppercases as per now@17 CLI version

Which led to the following specification:

• Branch naming, each official preset's branch must (in order):
  • Start with v (for "version", as Next.js and Zeit may evolve in the future, and require to provide different presets (old ones and new ones) while keeping the same features and vendors)
  • Then with the major version of the preset (i.e: 1)
  • Then with a ssr/ssg tag
  • Then with a mst tag (if multiple single-tenants design), or mt tag if multi-tenant (single-tenancy isn't something we aim to support, because MST is better (ROI), in our opinion)
  • Then, with a shortened list of all features/vendor differences with the "origin preset" (we can't list them all due to domain name characters limit (53 max))
    • e.g: v1-ssr-mst-aptd-gcms-lcz-sty (see full list)
• Zeit project naming, each official preset'snow.json file must (in order) :
  • Start with nrn-
  • Then with the branch name
  • Additionally, for mst branches, they will also specify "customer1" or customer2" at the end of the name

Examples:

Most complete example, with all 3rd parties, SSR and monorepo design

(basically what's currently in the master branch)

Branch name: v1-ssr-mst-aptd-gcms-lcz-sty
Zeit project's names: nrn-v1-ssr-mst-aptd-gcms-lcz-sty-c1, nrn-v1-ssr-mst-aptd-gcms-lcz-sty-c2 (in now.*.json files, as name)

Example without monorepo design (single-tenant instead)

Branch name: v1-ssr-mt-aptd-gcms-lcz-sty
Zeit project's names: nrn-v1-ssr-mt-aptd-gcms-lcz-sty
From: v1-ssr-mst-aptd-gcms-lcz-sty branch

Example without Locize 3rd party

Branch name: v1-ssr-mst-aptd-gcms-sty
Zeit project's names: v1-ssr-mst-aptd-gcms-sty
From: v1-ssr-mst-aptd-gcms-lcz-sty branch

Example without i18n nor monorepo

Branch name: v1-ssr-mt-aptd-gcms-sty
Zeit project's names: nrn-v1-ssr-mt-aptd-gcms-sty
From: v1-ssr-mt-aptd-gcms-lcz-sty branch (because it's the closest of what we need)

Needs checkup

• Quickly understanding which boilerplate to use based on my current requirements
  • The README will help users finding the most appropriate preset of the boilerplate that best fit their need, and will allow them to quickly clone the preset locally and see source code changes through PR diff
• Quickly clone the boilerplate I want to use (git clone specific branch)
  • The specific git clone command will be included in the preset documentation in the README
• Quickly see what changes have been applied to add/remove a feature compared to another preset
  • The source code changes will be available through the preset PR diff view, people will also have the ability to comment things they don't understand or don't agree with (community feedback)
• Ability to apply identical updates to multiple presets easily (ease to maintain all those presets by reducing issues when applying changes that are common to all, such as dependency updates, security updates, good practices, etc.)
  • Possible through cherry pick or git patches, straightforward as long as there are no conflict.

Feedback

Please share your questions, concerns or suggestion.

I'm getting this warning when building up on vercel:

WARNING: your application is being opted out of @vercel/next's optimized lambdas mode due to legacy routes in now.json. http://err.sh/vercel/vercel/next-legacy-routes-optimized-lambdas

When running yarn build on Windows on the v2-mst-aptd-gcms-lcz-sty branch I get

'NODE_ENV' is not recognized as an internal or external command

What is the purpose of creating a logger in some pages? in webstorm i have a lot of warnings from ts compiler TS6133: 'loger' is declared but its value is never read. Is it only there to be used if necessary?

There is a lot of console.* in pages as /src/pages/_error.tsx/ according to this rule I should replace it with logger.

Should it be ttl === 0 instead of timestamp === 0?

Wondering whether or not we should keep next-with-apollo considering that we could easily integrate graphql without it: https://github.com/vercel/next.js/blob/canary/examples/with-apollo/lib/apolloClient.js

next-with-apollo has a lot of dead code that are meant to be used with getInitialProps and getDataFromTree which has known performance issues.

What's your thoughts?

This prop is provided for all pages through MultiversalAppBootstrapPageProps
but not actually present in types SSGPageProps or SSRPageProps.
Why?
How to use it in pages without ts errors?

Build a Documentation Site via Github Pages

Circa the discussion in #18 (comment), it seems a fitting task to make a documentation website.

Resources

Here is one approach.
https://github.blog/2016-08-22-publish-your-project-documentation-with-github-pages/

An example of this is the Jekyll repo itself

You can see it here:
https://github.com/jekyll/jekyll/tree/master/docs

You said you were busy...

I don't mind taking a stab at building a simple docs jekyll site that I add to. This would of course require some kind of repo access. If you're uncomfortable with that, I can take a stab at trying to build my own github pages approach that you link to (but you will miss out on the tight coupling with your own repo and the ability to incorporate issues and pull requests)

Most importantly, using GitHub Pages means your documentation lives alongside your code on GitHub, where you can use things like Issues and Pull Requests to ensure it receives the high level of care it deserves; and because GitHub Pages lets you publish from the /docs directory on the master branch, you can maintain your codebase and its published documentation on the same branch.

Searching about locale fallback I came across this https://graphcms.nolt.io/35, and I noticed you're not using gcms-locale is it just because of the limitation of the locale in the free version of GraphCMS?

Isn't it better to add it and include the supported default supported locales we have even though it might not make effect for a free account at least people will know this is available.

Maybe I just misunderstood this.

Have you considered to use https://schema.org/ for better SEO experiences?

See https://github.com/lfades/next.js/tree/7b64cae6814fbc2a174632fe7833bba239bf9fd1/examples/with-sentry-simple

Most interesting tests are client/

I had tried to add more SSG tests like that for the server, but Vercel crashes during build and the whole build fails, so it's not possible to write meant-to-crash tests like that (hence the focus on the client, or maybe necessary to build those as SSR pages, but that'd count toward the 12 severless functions limit 😞 )

It's very likely that we may not add any more meaningful tests. But if it's possible to cover more use cases then it'd be a good thing.

So you're adding getInitialProps on _.app.tsx meaning that there is no SSG support, are you planning to change this to a more dynamic way to suport SSG and SSR?

Thanks!