1. 18 12月, 2018 1 次提交
  2. 17 12月, 2018 3 次提交
    • T
      v7.0.2-canary.48 · 6e2cbfaf
      Tim Neutkens 提交于
      6e2cbfaf
    • K
      Change page export validity check on client and server in development (#5857) · 72e79292
      Kyle Holmberg 提交于
      Resolves #4055 
      
      Credit: https://github.com/zeit/next.js/pull/5095
      
      I didn't use the ignore webpack plugin from the original PR and tested bundle size with https://github.com/zeit/next.js/pull/5339 - seems to be safe on that front.
      
      Was able to get tests to pass locally, unsure of what goes wrong in CI 🤷‍♂️ 
      
      **Questions**
      1) The initial PR didn't include changes to `next-server/lib/router` in `getRouteInfo()`. Should the same changes be made within?
      
      2) Should we add a test for rendering a component created via `forwardRef()`?
      
      `component-with-forwardedRef`:
      ```javascript
      export default React.forwardRef((props, ref) => <span {...props} forwardedRef={ref}>This is a component with a forwarded ref</span>);
      ```
      
      some test:
      ```javascript
      test('renders from forwardRef', async () => {
        const $ = await get$('/component-with-forwardedRef')
        const span = $('span')
        expect(span.text()).toMatch(/This is a component with a forwarded ref/)
      })
      ```
      72e79292
    • B
      Improve dev experience by listening faster (#5902) · b91a9601
      Brian Beck 提交于
      As I detailed in [this thread on Spectrum](https://spectrum.chat/?t=3df7b1fb-7331-4ca4-af35-d9a8b1cacb2c), the dev experience would be a lot nicer if the server started listening as soon as possible, before the slow initialization steps. That way, instead of manually polling the dev URL until the server's up (this can take a long time!), I can open it right away and the responses will be delivered when the dev server is done initializing.
      
      This makes a few changes to the dev server:
      
      * Move `HotReloader` creation to `prepare`. Ideally, more things (from the non-dev `Server`) would be moved to a later point as well, because creating `next({ ... })` is quite slow.
      * In `run`, wait for a promise to resolve before doing anything. This promise automatically gets resolved whenever `prepare` finishes successfully.
      
      And the `next dev` and `next start` scripts:
      
      * Since we want to log that the server is ready/listening before the intensive build process kicks off, we return the app instance from `startServer` and the scripts call `app.prepare()`.
      
      This should all be backwards compatible, including with all existing custom server recommendations that essentially say `app.prepare().then(listen)`. But now, we could make an even better recommendation: start listening right away, then call `app.prepare()` in the `listen` callback. Users would be free to make that change and get better DX.
      
      Try it and I doubt you'll want to go back to the old way. :)
      b91a9601
  3. 16 12月, 2018 8 次提交
  4. 15 12月, 2018 2 次提交
  5. 14 12月, 2018 7 次提交
  6. 13 12月, 2018 4 次提交
  7. 12 12月, 2018 7 次提交
    • B
      multi-threaded export with nice progress indication (#5870) · e6c36866
      Benjamin Kniffler 提交于
      This PR will
      
      - allow nextjs export to use all available CPU cores for rendering & writing pages by using child_process
      - make use of async-sema to allow each thread to concurrently write multiple paths
      - show a fancy progress bar while processing pages (with non-TTY fallback for CI web consoles)
      
      The performance gain for my MacBook with 4 CPU cores went from ~25 pages per second to ~75 pages per second. Beefy CI machines with lots of cores should profit even more.
      e6c36866
    • O
      Fix/update "examples/custom-server-typescript" (#5865) · 71d1d363
      Oscar Busk 提交于
      * Update all dependencies and remove redundant ones from package.json. (60f9ee5)
      * Fixes #5596 by adjusting nodemon scripts (d4b7d3a)
      * Fixes `npm start` on windows by using `cross-env` (9555217)
      * Move compiled server out from `.next`. Compiling other JS into `.next` seems incorrect. (79fce02, 
      9ce7086)
      * Partly fixes #5753 by making sure typescript compiles with `es2017` as target, at least ensuring code is runnable on node 8. Previously it was compiled with `esnext`. (9176e92)
      
      --- 
      
      I tried improving the structure by keeping source in `src/app` and `src/server` and then building to `dist/server` and `dist/app` but I didn't really get it to work and made most configs more complicated. Moved the built server out from `.next` anyway.
      71d1d363
    • B
      Fix initialNow in react-intl example (#5867) · 50662c6a
      Brian Beck 提交于
      The `initialNow` prop is used to avoid content mismatches when Universal/SSR apps render date values using components like `<FormattedRelative>`.
      
      If this value is created in `render()`, then the server will generate it and then the client will also generate it during hydration / initial render, resulting in two different values and content mismatches like:
      
      > Warning: Text content did not match. Server: "in 1,741,545 seconds" Client: "in 1,741,543 seconds"
      
      If the value is instead generated in `getInitialProps`, then the client's initial rendering will match because it will use the same value sent down by the server.
      50662c6a
    • O
      Update/fix "examples/with-firebase-hosting-and-typescript" (#5864) · 4345343d
      Oscar Busk 提交于
      There were several issues with the example [examples/with-firebase-hosting-and-typescript](https://github.com/zeit/next.js/tree/canary/examples/with-firebase-hosting-and-typescript)
      * `npm run serve`
        * Has no `pre` task that actually builds the app. Requires manual running of all build scripts.
        * Will choke on windows because trying to set environment variables with `NODE_ENV=production`
      * Outdated Typescript and Tslint
      * Not being able to deploy because `firebase-tools` being of a deprecated version.
      * Structure, which I understand is based on `firebase-tools` generation, is confising with `src/functions/src` being generally bad structuring.
      
      I remedied this and also improved some other factors:
      
      * Remove dependency `prettier` as it is unused (f4d6f54)
      * Upgrade all dependencies (09a9193)
        * Use upgraded firebase dependencies to deploy to node 8 environment (87e1e09, 7d8055b)
        * Remove deprecated tslint rule `no-unused-variable` (9392162)
      * Flattened filestructure in `src/functions` (097a25a)
      * Use ES import when importing next (6c99adb)
      * Fixed incorrect name and added somewhat to the description in package.json.
        `with-firebase-hosting` → `with-firebase-hosting-and-typescript` (1ffa0b5)
      * Fixed `serve` script by building before running, using [`cross-env`](https://www.npmjs.com/package/cross-env) to set environment variables and remove unecessary flag. (3a1e221, 422ccee, 8811e44)
      * Add `.firebase` cache to `.gitignore` (4d7cbe4)
      * Add `-C` (clean) flag when copying dependency files `copy-deps` (0826708)
      * Use `strict: true` in the functions tsconfig (229b04f)
      
      This was tested by running serve on windows and linx(WSL) and deploy on linux(WSL)
      
      ---
      
      This is based on #5819 but correctly based from `canary`
      4345343d
    • K
      Upgrade React from 16.4.2 to 16.6.3 (#5861) · d58cecc9
      Kyle Holmberg 提交于
      * Upgrade React version
      
      * Update size-limit test to account for React change
      d58cecc9
    • T
      v7.0.2-canary.42 · 2dec1fcd
      Tim Neutkens 提交于
      2dec1fcd
    • T
      5708e99e
  8. 11 12月, 2018 5 次提交
  9. 10 12月, 2018 3 次提交