This upgrades to ncc@0.25.0 and fixes the previous bugs including:
* ncc not referenced correctly in build
* Babel type errors
* node-fetch, etag, chalk and raw-body dependencies not building with ncc - these have been "un-ncc'd" for now. As they are relatively small dependencies, this doesn't seem too much of an issue and we can follow up in the tracking ncc issue at https://github.com/vercel/ncc/issues/612.
* `yarn dev` issues
Took a lot of bisecting, but the overall diff isn't too bad here in the end.
Disambiguate between pages/index.js and pages/index/index.js so that they resolve differently.
It all started with a bug in pagesmanifest that propagated throughout the codebase. After fixing pagesmanifest I was able to remove a few hacks here and there and more logic is shared now. especially the logic that resolves an entrypoint back into a route path. To sum up what happened:
- `getRouteFromEntrypoint` is the inverse operation of `getPageFile` that's under `pages/_document.tsx`
- `denormalizePagePath` is the inverse operation of `normalizePagePath`.
Everything is refactored in terms of these operations, that makes their behavior uniform and easier to update/patch in a central place. Before there were subtle differences between those that made `index/index.js` hard to handle.
Some potential follow up on this PR:
- [`hot-reloader`](https://github.com/vercel/next.js/pull/13699/files#diff-6161346d2c5f4b7abc87059d8768c44bR207) still has one place that does very similar behavior to `getRouteFromEntrypoint`. It can probably be rewritten in terms of `getRouteFromEntrypoint`.
- There are a few places where `denormalizePagePath(normalizePagePath(...))` is happening. This is a sign that `normalizePagePath` is doing some validation that is independent of its rewriting logic. That should probably be factored out in its own function. after that I should probably investigate whether `normalizePagePath` is even still needed at all.
- a lot of code is doing `.replace(/\\/g, '')`. If wanted, that could be replaced with `normalizePathSep`.
- It looks to me like some logic that's spread across the project can be centralized in 4 functions
- `getRouteFromEntrypoint` (part of this PR)
- its inverse `getEntrypointFromRoute` (already exists in `_document.tsx` as `getPageFile`)
- `getRouteFromPageFile`
- its inverse `getPageFileFromRoute` (already exists as `findPageFile ` in `server/lib/find-page-file.ts`)
It could be beneficial to structure the code to keep these fuctionalities close together and name them similarly.
- revise `index.amp` handling in pagesmanifest. I left it alone in this PR to keep it scoped, but it may be broken wrt nested index files as well. It might even make sense to reshape the pagesmanifest altogether to handle html/json/amp/... better
* fix(debugging): do not pass NODE_OPTIONS='--inspect' to subprocesses
fixes#11030
* fix(debugger): use a regex to remove bad NODE_OPTIONS flags
Co-authored-by: Alec Larson <alec.stanford.larson@gmail.com>
* Convert Dev Server to TypeScript
This converts the Next.js Development Server to TypeScript in prep for upcoming changes.
* Convert remaining necessary
* Fix some type errors
* Adjust types
* Fail build on duplicate pages
This will fail the `next build` command when a duplicate page is found.
In development, we'll emit a warning instead of crashing the dev server.
* Add test for warning in development
* Only issue a warning
* Fix production test
* Fix development test
* Remove useless arg
* Warn in development, too
* Run prettier over packages/**/*.js
* Run prettier over packages/**/*.ts
* Run prettier over examples
* Remove tslint
* Run prettier over examples
* Run prettier over all markdown files
* Run prettier over json files
* Add WithAmp to enable AMP support for
pages instead of .amp.js
* Update handling for exporting AMP
* Fix ampPath in export for / path and
revert isAmp logic to handle right
* Update amphtml test suite
* Add handling for noDirtyAmp during
export and update amp-export test suite
* Update serverless and export-default-map
test suites
* Update require-page tests
* Add support for .amp.js pages and
resolving /page?amp=1 to page.amp.js
* Update amp tests
* Update example and clean up amp page resolving
* Add nested amp test
* page => normalizedPage
* Add type to page options
* Add handling of amp with all pageExtensions
and normalize page
* Make sure findPageFile only falls back to
amp if enabled
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)
* fix(launch-editor): resolve filename including current working directory
* refactor: handle when fileName is already absolute
* feat: use Next.js dir instead of process.cwd()
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. :)
