Next.js: Ensure ergonomic handling of non-page in `./pages/`

[Timer]

We need to make sure there's a sufficiently informative error displayed.

[timneutkens]

$ next build
Creating an optimized production build ...

> Using external babel configuration
> Location: "/Users/timneutkens/projects/something/.babelrc"
Failed to compile.

./node_modules/next/dist/build/webpack/loaders/next-serverless-loader.js?page=%2Fhome%2Fstyles&absolutePagePath=private-next-pages%2Fhome%2Fstyles.js&absoluteAppPath=next%2Fdist%2Fpages%2F_app&absoluteDocumentPath=private-next-pages%2F_document.js&absoluteErrorPath=next%2Fdist%2Fpages%2F_error&distDir=private-dot-next&assetPrefix=&generateEtags=true&ampBindInitData=false&canonicalBase=&dynamicBuildId=false
Attempted import error: 'private-next-pages/home/styles.js' does not contain a default export (imported as 'ComponentInfo').

> Build error occurred
Error: > webpack config.resolve.alias was incorrectly overriden. https://err.sh/zeit/next.js/invalid-resolve-alias
    at build (/Users/timneutkens/projects/something/node_modules/next/dist/build/index.js:6:235)
    at processTicksAndRejections (internal/process/next_tick.js:81:5)
error Command failed with exit code 1.

For reference this is what needs fixing 👍

[nataliemarleny]

🙋🏻‍♀️ Am going to have a go at solving this one

[LinusU]

Is there no longer going to be a way to store non-page files in the pages folder at all? I'm currently working in a rather large project where the setup looks something like this:

• components
  
  
  
  • project wide components
  
  
• lib
  
  
  
  • project wide shared code
  
  
• pages
  
  
  
  • projects
  
  
  • _header.js # this file is used by the other files in this folder
  
  
  • edit.js
  
  
  • list.js
  
  
  • view.js
  
  
  • users
  
  
  • ...
  
  
  • ...
  
  

It seems like upgrading to Next.js 9 is going to be a huge undertaking for us, since we have to move out all files with components specific to a part of the site into the global components folder.

I'm also not sure how to best structure with the new way, since many of the components are very specific to that part of the site, and I don't really want to put them in the global components library. (e.g. both projects, users and news have their own _header.js)

Any pointers on how we should move forward?

[timneutkens]

Is there no longer going to be a way to store non-page files in the pages folder at all? I'm currently working in a rather large project where the setup looks something like this:

Actually you introduced a massive build slowdown by putting components into the pages directory, every component was already turned into a page.

[nataliemarleny]

@timneutkens and @Timer - what would be the consensus on a more informative error message? Recreating the issue locally, the error message I received for Next 9.0.0 was:

$ npm run build

> [email protected] build /Users/nataliemarleny/OpenSource/nextjs-sandbox
> next build

Creating an optimized production build ...

Compiled successfully.

> Build error occurred
Error: autoExport failed: found page without React Component as default export
pages/styles

See https://err.sh/zeit/next.js/page-without-valid-component for more info.

    at build (/Users/nataliemarleny/OpenSource/nextjs-sandbox/node_modules/next/dist/build/index.js:6:3267)
    at process._tickCallback (internal/process/next_tick.js:68:7)

It contains:

• Detailed error message
• A link to documentation for more info
• A stack-trace

[timneutkens]

Actually that seems great! however the error I got was when

module.exports = {target: 'serverless'}

So basically replicating what you saw for the serverless target would be perfect 😌

[timneutkens]

Error: autoExport failed: found page without React Component as default export pages/styles

Looks like this wording needs to be updated from autoExport failed to automatic static optimization failed

cc @Timer, thoughts?

[Timer]

We'd need to do a blanket rename of everything we have from Automatic Prerendering to Automatic Static Optimization, but I think that's the direction we're headed @timneutkens. So 👍.

[Timer]

Tagging this for 9.0.2 because it's important we give our users a friendly error. 😄

[ggaulard]

Is there no longer going to be a way to store non-page files in the pages folder at all? I'm currently working in a rather large project where the setup looks something like this:

Actually you introduced a massive build slowdown by putting components into the pages directory, every component was already turned into a page.

Sorry but I'm a little surprise to just discover this now, After lot of time consulting the documentation.
Having all our component way far in some global component folder is not scalable for huge projects.
Close components have to stay close.
I just checked the actual documentation is the configuration in the doc :
// next.config.js
module.exports = {
pageExtensions: ['mdx', 'jsx', 'js']
};
can solve the issue ? have pages with extension mdx and components with tsx ?
@timneutkens
Thanks

Edit : it does the job 👍

[AmazingTurtle]

I'm runnig latest [email protected] and the issues does still occur. Any thoughts?

Error: automatic static optimization failed: found page without a React Component as default export in
context/authenticationContext

I'm using the React context:

import React from 'react';

interface AuthenticationContext {
  authenticated: boolean;
}

export const AuthenticationContext = React.createContext<AuthenticationContext>({
  authenticated: false,
});

edit:
fixed it in my case by adding the following lines to my context file:

const AuthenticationContextProvider = AuthenticationContext.Provider;

export { AuthenticationContextProvider };
export default AuthenticationContextProvider;

[timneutkens]

fixed it in my case by adding the following lines to my context file:

Note that this is not a fix. Don't put non-pages in the pages directory.

[AmazingTurtle]

@timneutkens the file is not in pages directory. It was in a directory next to it (context/)

[timneutkens]

@AmazingTurtle that's strange 🤔 Considering pages are the only ones that are checked.

[AmazingTurtle]

Weired, maybe I was wrong with the folder @timneutkens. I will double check tomorrow.

[afaqahmedkhan]

Only way to resolve this is to move all non page components/interfaces out of pages folder

[cristian-eriomenco]

Next.js routing system and folder structure is terrible.

The story repeats itself numerous time over years and there seem to be no learnings from past mistakes (PHP, ASP.NET, WebForms etc).

I do understand what "opinionated" means but simply put, the opinion of creating a 1:1 bond between folderstructure and routing does not have any sensible foundation. Thats a perfect example, where "convention over configuration" does not work.

• Naming files like [[...slug]].js or [id]/[category].js
• Not being able to follow a "features" based folder structure where highly cohesive components and assets are grouped under same folder, only via hacks with mirrored/proxy "pages" folder
• Broken navigation in IDEs due to funny file names
• Poor refactoring constraints, where filename is based on the url params. Imagine multiple people working on same file.

Stop grouping files by extension eg:
/assets/css/home.css
/assets/img/promoImage.jpeg
/lib/carousel/carousel.js
/pages/home/index.js

Instead group them by coupling/relevance/cohesiveness:
/pages/home/home.js
/pages/home/home.css
/pages/home/components/carousel.js
/pages/home/......

And if its something reusable, great create a folder at top or extract it into its own NPM package where you'd have strict unit test coverage, linting rules, storybook or other showcasing UI, API referecence and patronized check-ins.

Deleting the /home directory i remove the feature in 1 click, no dependencies are broken. Navigation in IDE is simple. Routing is decoupled.

If the framework relies on walking through the directories based on "naming convention"only well then this sucks, offer a way to configure/map/mark/decorate/whatever so this relationship is not tightly coupled and forced onto the user.

Sorry for long winded answer but in pains me a lot...