- Update to latest stripe-node version and pin the exact version so the Types won't go out of sync
- Add the env var changes for next 9.4.4 (https://nextjs.org/blog/next-9-4#new-environment-variables-support)
- Remove `next.config.js` as no longer needed.
- Add the Deploy to Vercel button
* created with-mongodb, Next.js + MongoDB
Co-authored-by: Shania Dhani <31454777+sdhani@users.noreply.github.com>
Co-authored-by: Michelle Lucero <31500626+MichelleLucero@users.noreply.github.com>
Co-authored-by: Chi Shing Lee <60354073+chislee0708@users.noreply.github.com>
* Update examples/with-mongodb/README.md
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
* modified for dotenv and environment var setup
* removed extra instructions on readme, linked it to the MongoDB guides
* changes to environment var
* replaced document with react logic
* removed Pet header
* removed isomorphic-unfetch
* replaced getInitialProps with getStaticProps (SSG)
* removed console log
* deleted next.config.js file
* fixed prettier styling
* fixed link 404 server rendering issue
* modified server path for delete/edit
* fixed prettier styling
* fixed a typo
* change .env to .env.local
Co-authored-by: Joe Haddad <timer150@gmail.com>
* fixed typo, change .env to .env.local
Co-authored-by: Joe Haddad <timer150@gmail.com>
* change .env to .env.local
Co-authored-by: Joe Haddad <timer150@gmail.com>
* Update examples/with-mongodb/package.json
Co-authored-by: Joe Haddad <timer150@gmail.com>
* removed dotenv dev dependency
Co-authored-by: Joe Haddad <timer150@gmail.com>
* cleaned up code and instructions
* Update examples/with-mongodb/.gitignore
Co-authored-by: Luis Alvarez D. <luis@vercel.com>
* minor changes to code style and logic
* Updated index page and .env.local.example
* Updated new page
* Don't use SSG for the edit page
* Fixed revalidation issue
* Use es6 for the model
* Updated edit page
* Removed VERCEL_URL
* Updated readme and renamed env
* Added temporal vercel.json
* Removed seed until added with a script
* Updated package.json
* Renamed example in readme
* Renamed example
* Lint fix
Co-authored-by: liulanz <zhengliulan@gmail.com>
Co-authored-by: Shania Dhani <31454777+sdhani@users.noreply.github.com>
Co-authored-by: Chi Shing Lee <60354073+chislee0708@users.noreply.github.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: sdhani <shania.dhani46@myhunter.cuny.edu>
Co-authored-by: liulanz <37808313+liulanz@users.noreply.github.com>
Co-authored-by: Joe Haddad <timer150@gmail.com>
Co-authored-by: Luis Alvarez D. <luis@vercel.com>
This PR fixes https://github.com/vercel/next.js/issues/7769.
However, I would like for @jayu to confirm that it's ok to use the latest Linaria 2.0 alpha release. I can confirm from my local testing that it's working as expected.
Since non-fallback pages don't rely on the URL for hydration we can allow them to be rewritten to but pages with fallback still can't be rewritten to because we won't be able to parse the correct `/_next/data` path to request the page's data from. I added a test for this behavior and ensured it works correctly on Now.
Example on with fallback false rewrite on Now:
https://tst-rewrite-cp9vge4bg.now.sh/about
This code existed mostly to work around webpack 2 (yes 2.x) limitations where it crashed in certain cases where files didn't exist anymore. We have tests for that behavior and latest webpack has fixed these. Hence why this can be removed 👍
This removes `fork-ts-checker-webpack-plugin` and instead directly calls the TypeScript API.
This is approximately 10x faster.
Base build: 7s (no TypeScript features enabled)
- `fork-ts-checker-webpack-plugin@3.1.1`: 90s, computer sounds like an airplane
- `fork-ts-checker-webpack-plugin@4.1.6`: 84s, computer did **not** sound like an airplane
- `fork-ts-checker-webpack-plugin@5.0.0-alpha.14`: 90s, regressed
- `npx tsc -p tsconfig.json --noEmit`: 12s (time: `18.57s user 0.97s system 169% cpu 11.525 total`)
- **This PR**: 22s, expected to get better when we run this as a side-car
All of these tests were run 3 times and repeat-accurate within +/- 0.5s.
This pull request refactors our TypeScript preflight check in preparation for dropping the `fork-ts-checker-webpack-plugin` plugin.
This will make reviewing the subsequent PR much easier.
---
There is no behavior change, so the existing test should cover this adequately.
Resolves: https://github.com/zeit/next.js/issues/12545
This PR adds an example which show how to bundle and use WebWorkers in a next.js app.
The issue mentions Typescript, but adding typescript to the example should be fairly simple by following the documentation and seems out of scope for a web-worker example.
By default, webpack will proceed to run loaders and plugins on all files, even after an error has been encountered during the build process.
This means you might need to wait minutes to see a syntax error encountered in one of your source files. This PR fixes that.
@lfades hope this works. I have updated the example to show differences between client/ssr/ssg initial state in redux. Let me know if something needs to be changed.
This adds `InferredStaticProps` and `InferredServerSideProps` to the typings.
- [x] add types for type inference
- [x] add explanation to docs
- [ ] tests - are there any?
### What does it do:
As an alternative to declaring your Types manually with:
```typescript
type Props = {
posts: Post[]
}
export const getStaticProps: GetStaticProps<Props> = () => ({
posts: await fetchMyPosts(),
})
export const MyComponent(props: Props) =>(
// ...
);
```
we can now also infer the prop types with
```typescript
export const getStaticProps = () => ({
// given fetchMyPosts() returns type Post[]
posts: await fetchMyPosts(),
})
export const MyComponent(props: InferredStaticProps<typeof getStaticProps>) =>(
// props.posts will be of type Post[]
);
```
### help / review wanted
- [ ] I am no typescript expert. Although the solution works as intended for me, someone with more knowledge could probably improve the types. Any edge cases I missed?
- [ ] are there any tests I should modify/ add?
This pull request updates our TypeScript verification process to not wipe out potentially vital user comments.
Introducing a prompt process was mostly a side effect of users wanting to keep comments.
There's no reason we really need this prompt, as answering no would refuse to boot the Next.js server anyway.
---
Fixes#8128Closes#11440
1. I updated all the packages.
2. Refactored the home component from class to functional
3. Example now uses getServerSideProps instead of getInitialProps
## What
An example to show how you can create a static generated build of Next.js (using the new `getStaticProps` and `getStaticPaths` functions) with data fetched from a local GraphQL schema. The same schema is used to host a GraphQL endpoint using the API Route `/api/graphql`.
## Why
I was setting up a static hosted website whereby data is stored in a set of local JSON files (pulled from a backend server at build time). I wanted to consume the content using the developer benefits that GraphQL provides and using a consistent interface the GraphQL API consumers would be using.
Within my page components I initially made GraphQL `fetch` calls to the locally running `/api/graphql` endpoint which worked well with `npm run dev`, however when it came to `npm run build` that endpoint was inaccessible (I tried both VERCEL_URL and localhost:3000) - which is now understandable given I read further the "[Write server-side code directly](https://nextjs.org/docs/basic-features/data-fetching#write-server-side-code-directly)" documentation.
This example may or may not be useful for others so please feel free to close, but I thought I would contribute incase it assisted others.
## Related Discussions
It looks as though this PR may help with some of the following discussions:
- https://github.com/zeit/next.js/discussions/12785
- https://github.com/zeit/next.js/discussions/10946
- https://github.com/zeit/next.js/discussions/12182
- https://github.com/zeit/next.js/discussions/11285
## Related Examples
The end solution for this PR was a combination of web discussions and seeing the `api-routes-graphql` example. Perhaps this PR should just update that example to use the new methods? Or maybe it is worth having both?
- https://github.com/zeit/next.js/blob/canary/examples/examples/api-routes-graphql
This is also similar to this example, although that example has more code in order to provide isomorphic Apollo Client for client side code use.
- https://github.com/zeit/next.js/blob/canary/examples/api-routes-apollo-server-and-client
## Errors Recieved
I've included the below errors as they are the ones I faced when figuring out the end solution. These may just help with SEO for others googling the same issue.
### Error when trying to use localhost:3000
```
> Build error occurred
{ FetchError: request to http://localhost:3000/api/graphql failed, reason: connect ECONNREFUSED 127.0.0.1:3000
at ClientRequest.<anonymous> (/vercel/7cf60e2b/.next/serverless/pages/content.js:1999:147829)
at ClientRequest.emit (events.js:198:13)
at Socket.socketErrorListener (_http_client.js:401:9)
at Socket.emit (events.js:198:13)
at emitErrorNT (internal/streams/destroy.js:91:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
at process._tickCallback (internal/process/next_tick.js:63:19) type: 'system', errno: 'ECONNREFUSED', code: 'ECONNREFUSED' }
```
### Error when trying to use VERCEL_URL
```
> Build error occurred
{ FetchError: invalid json response body at https://vercel.com/login?next=%2Fdeployments%2Fprojectnamehere.now.sh%3Fhost%3Dprojectnamehere.now.sh%26redirect%3D1%26section%3D reason: Unexpected token < in JSON at position 0
at /vercel/3d91c11/node_modules/next/dist/compiled/node-fetch/index.js:1:133590
at process._tickCallback (internal/process/next_tick.js:68:7) type: 'invalid-json' }
```
This makes sure we don't duplicate the `/` route or any others while exporting with `exportTrailingSlash` enabled. We do still output `404.html` with `exportTrailingSlash` enabled in case anyone was relying on this file being present.
Fixes: https://github.com/zeit/next.js/issues/11008
This fixes an edge case where an application can seemingly randomly be opted out of the automatic static optimization from having an `_error` file that isn't directly nested under the `pages` folder e.g. `pages/hello/_error.js`.
Since in serverless mode we use the `_app` export from the first serverless page, if this `_error.js` file is used to check for custom `getIniitalProps` in `_app` and the `_error.js` page had a custom `getInitialProps` itself it would cause the check to fail opting the application out of the static optimization.
This fixes it by having the check be explicit instead of relying on the bundle name and it also adds regression tests for this. It might be good to also add a warning when `_error` or `_app` are not directly nested under the pages folder in a follow up PR
**Affected examples**
with-segment-analytics
with-slate
with-portals-ssr ( _with-portals-ssr is based on a package not being updated in the last year_)
with-videojs
with-next-page-transitions
with-firebase-cloud-messaging
with-dynamic-app-layout
with-dynamic-import
with-next-transition
with-carbon-components
with-cerebral
with-custom-babel-config
Here and there I have removed some redundant imports as well. I believe with this PR, there are only 1 or 2 examples left using class-based components. If by any chance you find any, let me know and I'll refactor them too.
If you don't like anything or you want me to change something, please let me know.
**If there is anything else you'd like me to help with, I would be honored to assist.**
