- 24 3月, 2019 1 次提交
-
-
由 Tim Neutkens 提交于
* Remove hoist-non-react-statics from with-router * Drop hoist-non-react-statics from package.json
-
- 20 3月, 2019 1 次提交
-
-
由 JJ Kasper 提交于
* Break out client-navigation and rendering test from basic test * Try with parallelism dialed back to 3 * Update jest-junit for more compatible timings in CircleCI * Bump to test timings * Use filepath for suitename in jest-junit * Store reports as artifacts * Try using classname for timings * Bump * Remove reports from artifacts
-
- 19 3月, 2019 1 次提交
-
-
由 Joe Haddad 提交于
-
- 13 3月, 2019 1 次提交
-
-
由 Joe Haddad 提交于
* Inject the build ID after webpack runs * add webpack sources types * use webpack plugin instead * reset file * Skip source maps if none were provided Co-Authored-By: NTimer <timer150@gmail.com>
-
- 12 3月, 2019 1 次提交
-
-
由 JJ Kasper 提交于
-
- 10 3月, 2019 1 次提交
-
-
由 Tim Neutkens 提交于
While this is a nice feature it does filesystem operations to check if the resolved file matches the filesystem.
-
- 08 3月, 2019 2 次提交
- 07 3月, 2019 1 次提交
-
-
由 Tim Neutkens 提交于
More cleanup of terser-plugin.
-
- 05 3月, 2019 2 次提交
-
-
由 Connor Davis 提交于
Removes `rimraf` for a smaller custom lib Benchmarks (in ms): ``` rimraf 1 518.536376 rimraf 2 416.112451 rimraf 3 451.905842 rimraf 4 525.117395 rimraf 5 434.230384 ---- Average: 469.18ms ----------- recursive delete 1 121.493979 recursive delete 2 130.335272 recursive delete 3 149.798316 recursive delete 4 182.184688 recursive delete 5 130.346207 --- Average: 142.83ms ``` `recursiveDelete` finishes in ~30% of the time it takes `rimraf` (3.3 times faster)
-
由 JJ Kasper 提交于
At request of @timneutkens I moved the `next-mdx` plugin from the next-plugins repo into Next.js. Also fixed small typo in README under setup.
-
- 02 3月, 2019 1 次提交
-
-
由 Joe Haddad 提交于
-
- 27 2月, 2019 1 次提交
-
-
由 Connor Davis 提交于
-
- 25 2月, 2019 1 次提交
-
-
由 Connor Davis 提交于
We don't use a lot of the features of `glob`, so let's remove it in favor of a leaner approach using regex. It's failing on windows and I have no idea why and don't own a windows machine
🤦 🏼 ♂️ (Ignore some of the commits in here, I forgot to create the new branch before I started working)
-
- 23 2月, 2019 6 次提交
-
-
由 Tim Neutkens 提交于
-
由 Connor Davis 提交于
-
由 Tim Neutkens 提交于
-
由 Tim Neutkens 提交于
-
由 Connor Davis 提交于
* Add ncc taskfile * Add ncc dep and pass options * dev dep
-
由 Tim Neutkens 提交于
-
- 22 2月, 2019 1 次提交
-
-
由 Tim Neutkens 提交于
-
- 21 2月, 2019 3 次提交
-
-
由 Joe Haddad 提交于
-
由 Joe Haddad 提交于
* Make console output well behaved * Fix bad rebase
-
由 Connor Davis 提交于
-
- 20 2月, 2019 3 次提交
-
-
由 Joe Haddad 提交于
-
由 Connor Davis 提交于
Upgrades `standard` to major version 12
-
由 JJ Kasper 提交于
After talking with @timneutkens it was decided it'd be more streamlined to replace the onDemandEntries WebSocket with an alternative. Using the EventSource connection gives us these benefits over the WebSocket one: - less code needed - no extra server running - no extra config for onDemandEntries
-
- 17 2月, 2019 1 次提交
-
-
由 Joe Haddad 提交于
* Remove usage of WebpackBar and Friendly Errors * Add new clearConsole helper * Add new simplified output for development mode * Add an explicit bootstrapping mode * Add missing returns * Use existing output style * Adjust first output to say Waiting on * Only print URL if present
-
- 14 2月, 2019 1 次提交
-
-
由 Tim Neutkens 提交于
* Add initial AMP implementation * Implement experimental feature flag * Implement feedback from sbenz * Add next/amp and `useAmp` hook * Use /:path*/amp instead * Add canonical * Add amphtml tag * Add ampEnabled for rel=“amphtml” * Remove extra type
-
- 12 2月, 2019 1 次提交
-
-
由 Connor Davis 提交于
-
- 11 2月, 2019 1 次提交
-
-
由 Tim Neutkens 提交于
-
- 10 2月, 2019 1 次提交
-
-
由 Tim Neutkens 提交于
-
- 08 2月, 2019 1 次提交
-
-
由 Alexander Nanberg 提交于
AFAIK this dependency isn't being used anywhere so it should be safe to remove it.
-
- 27 1月, 2019 1 次提交
-
-
由 Tim Neutkens 提交于
* Implement circular JSON err.sh link * Add test for getInitialProps returning circular json * Make test warn less * Fix tests * Add reference to original tests
-
- 24 1月, 2019 1 次提交
-
-
由 Connor Davis 提交于
We want our new memory optimizations (https://github.com/webpack/webpack/pull/8609)
-
- 21 1月, 2019 2 次提交
-
-
由 Connor Davis 提交于
-
由 Connor Davis 提交于
-
- 09 1月, 2019 1 次提交
-
-
由 Tim Neutkens 提交于
* Remove unused argument * Replace pages-plugin with loader * Add loader-utils types * Remove logs * Bring back previous deposal behavior * Remove console.log * Remove webpack/utils as it’s no longer in use * Remove hot-self-accept-loader * Error Recovery tests * Make hotSelfAccept a noop default loader * Fix windows deleted/added * Remove logging * Remove unused variables * Remove log * Simplify entrypoint generation * Don’t return the function * Fix _app test * Remove code that’s always true * Move aliases to constants * Use alias * Join pages alias in reduce * Default pages differently * Loop over pages instead of manually defining * Move entry generation into common function * Update packages/next/build/webpack/loaders/next-client-pages-loader.ts Co-Authored-By: Ntimneutkens <tim@timneutkens.nl> * Update packages/next/build/webpack/loaders/next-client-pages-loader.ts
-
- 02 1月, 2019 1 次提交
-
-
由 Tim Neutkens 提交于
-
- 28 12月, 2018 1 次提交
-
-
由 Tim Neutkens 提交于
**This does not change existing behavior.** building to serverless is completely opt-in. - Implements `target: 'serverless'` in `next.config.js` - Removes `next build --lambdas` (was only available on next@canary so far) This implements the concept of build targets. Currently there will be 2 build targets: - server (This is the target that already existed / the default, no changes here) - serverless (New target aimed at compiling pages to serverless handlers) The serverless target will output a single file per `page` in the `pages` directory: - `pages/index.js` => `.next/serverless/index.js` - `pages/about.js` => `.next/serverless/about.js` So what is inside `.next/serverless/about.js`? All the code needed to render that specific page. It has the Node.js `http.Server` request handler function signature: ```ts (req: http.IncomingMessage, res: http.ServerResponse) => void ``` So how do you use it? Generally you **don't** want to use the below example, but for illustration purposes it's shown how the handler is called using a plain `http.Server`: ```js const http = require('http') // Note that `.default` is needed because the exported module is an esmodule const handler = require('./.next/serverless/about.js').default const server = new http.Server((req, res) => handler(req, res)) server.listen(3000, () => console.log('Listening on http://localhost:3000')) ``` Generally you'll upload this handler function to an external service like [Now v2](https://zeit.co/now-2), the `@now/next` builder will be updated to reflect these changes. This means that it'll be no longer neccesary for `@now/next` to do some of the guesswork in creating smaller handler functions. As Next.js will output the smallest possible serverless handler function automatically. The function has 0 dependencies so no node_modules are required to run it, and is generally very small. 45Kb zipped is the baseline, but I'm sure we can make it even smaller in the future. One important thing to note is that the function won't try to load `next.config.js`, so `publicRuntimeConfig` / `serverRuntimeConfig` are not supported. Reasons are outlined here: #5846 So to summarize: - every page becomes a serverless function - the serverless function has 0 dependencies (they're all inlined) - "just" uses the `req` and `res` coming from Node.js - opt-in using `target: 'serverless'` in `next.config.js` - Does not load next.config.js when executing the function TODO: - [x] Compile next/dynamic / `import()` into the function file, so that no extra files have to be uploaded. - [x] Setting `assetPrefix` at build time for serverless target - [x] Support custom /_app - [x] Support custom /_document - [x] Support custom /_error - [x] Add `next.config.js` property for `target` Need discussion: - [ ] Since the serverless target won't support `publicRuntimeConfig` / `serverRuntimeConfig` as they're runtime values. I think we should support build-time env var replacement with webpack.DefinePlugin or similar. - [ ] Serving static files with the correct cache-control, as there is no static file serving in the serverless target
-