-
Notifications
You must be signed in to change notification settings - Fork 26.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add pagesDir config option #4315
Comments
@vladnicula if your goal is to have everything that is webpacked/babeled and part of next be in the /src folder you can just move your pages directory into src and change your path for next to /src. We actually went one step further and moved our next configuration into a specific folder and our "userland" source code into src. all that exists in our "next" folder is /pages and next.config.js. we modified next.config.js to tell it to work its magic on the src folder. module.exports = {
webpack: (config, { dev, defaultLoaders }) => {
config.module.rules.push({
test: /\.+(js)$/,
loader: defaultLoaders.babel,
include: path.resolve(__dirname, '../src'),
});
return config;
}
}; |
@vladnicula take a look #819 (comment) |
@brad-decker we did something like this with next
but the issue here that @joao-alberto your solution can be apply with next but not with the custom server |
@joao-alberto thanks for the share. I actually did try to follow the steps from the ticket. The issue with that is that with a custom server we could not get the config to properly load and find the pages folder in development mode. So, the suggestion from #819 (comment) does not work in dev mode when using a custom server. We could come up with an isolate example to showcase the limitation if it would help this discussion. |
@brad-decker thanks for sharing that configuration nugget. I gave it a try and it seems that the dev mode was not able to find any of the pages under return app.render(req, res, '/') or return app.render(req, res, '/src') But it seems it did not want to. Attempting to bundle in production via I liked the idea anyway. |
Our app structure:
initialize app using the next folder add the blip from my previous comment to tell webpack to compile and bundle your /src folder |
also our .next folder gets added to the /next folder so our build stuff goes in next/.next which is so obviously next level |
Any thoughts on this somewhat alternative approach? The main purpose of that PR is to add support for multiple pages directories, but it could also be used to embed files under a different root. Sample module.exports = {
rootPaths: ['./src']
} |
Could this issue be looked at again please? 🙏 I used to keep all my Next.js app sources inside The fact that I'll have to have Unlike CRA, which is zero-config in principle, Next.js has quite a few options, including a bunch of experimental ones. It feels like swapping the hard-coded Relevant concerns, which were recently raised: #7798, #7782 Partially the reason why I'm asking is because our company looks into moving a few apps from bespoke webpack-dev-server configs into Next.js. Not being able to configure |
Pretty surprised this is not possible, and its a put-off/downside as I'm investigating migrating my CRA app to next.js. |
@gc CRA doesn't allow these types of settings to be adjusted, so the experience should be familiar. 😄 e.g. you cannot customize the |
Which is great, because it means that the entry point |
@kachkaev I'm well aware 😄. The above response was specifically directed at @gc, not this issue as a whole. There's many benefits to have an application rooted within We'll be drawing up a proposal soon that allows users to opt-into this rooting behavior. |
@Timer I was referring to not being able to have all the source in src/, this is the way I structure all my projects, for obvious reasons it's neater and more manageable. I'd rather not have to look through my many dotfiles, lock/log files, etc to find source code. I'm aware CRA (and next) are restricting things as you say, but if I'm understanding correctly, next.js is hardcoded to check only the root for /pages, so I cannot include it in my src. If I've misunderstood anything I apologize, I've only just started using next in the last few hours. @kachkaev has pretty well described my feelings too. I'm glad to hear about the proposal, I'm guessing it will let us specify a directory in our next.config? Like |
The proposal would look more like |
Very excited to see this being considered. Trying to build any kind of complex application with |
Just to be clear I'm strongly against any config value for this, we've seen tons of misusage of config values like these (looking at |
This would already be a huge improvement 🙏🏻 Please make |
If there is no intent to make |
@kachkaev that's exactly what I outlined 😄 |
This comment has been minimized.
This comment has been minimized.
Posted #8451 |
YES YES HELL YES FINALLY YES! Thanks folks :) |
I dont understand your choice @timneutkens … You are strongly against any config value but you want to let the user have the choice between The majority of the people are happy with only the possibility to put the pages folder inside the Your choice to support either I think the framework should be agnostic of each user project and folder structures. I think the choice to freeze the project structure breaks a common software engineering principle. The framework realise assumptions about the project structure. It breaks the Single Responsibility Principle in object oriented programming. Or, if you prefer, one of Linux principles that suggests that a software does one thing well, but only one thing. The aim of NextJS is to server-side render React. Not to suggests how the user has to organise his project. I would be happy to deeply understand why you don't want to leave the choice to the user. I read many threads about this discussion but I still don't understand. The framework will only be more powerful as it will be more adaptable. |
The premise is convention over configuration. Next.js is not a library, it does more than a single thing by design. It's a collection of:
The Next.js CLI is a compiler/bundler, but not a conventional one, as it compiles much more than the general compiler. A basic compiler takes Hence why Next.js is a framework and not a library that does a single thing.
This is a wrong assumption. As said earlier the main goal for Next.js is to have the right defaults for building websites / web applications and giving flexibility between tradeoffs (eg static, ssr, etc) while putting you / your team into the pit of success.
There are tradeoffs and impact in adding new features, the (negative) impact of allowing setting the pages directory does not outweigh the arguments for allowing it, we've seen this before with So yes, we're careful in adding new features, because we want you to not get stuck on a certain version and we want to guarantee that they'll continue working in the future. The best example of this is probably that almost all features outlined in Next.js 1 are still fully compatible with Next.js 9.
Besides what I've written above there is this reply: #8451 (comment) |
Well then, you're assumptions about this particular issue is off compared to many people who voiced their opinions. In the end it's you and the team that needs to support this, so whatever works for you best should be the way to go forward. I wouldn't want to maintain a large codebase that does not follow my ideals. I hope you also understand that this kind of decisions are strongly polarizing. For my case, nextjs falls down from a tool that I really like to use to a tool I just pick when I want to get something done really fast, without much certainty of customization or long term support. |
This comment captures part of why we shouldn't allow it: #8451 (comment) It's hard to argue that anyone:
Maybe you're building short term projects, but there are thousands of actively worked on projects using Next.js. This ranges from the 6th largest website of the internet (by Alexa rank) to personal websites.
Note that I wouldn't use The discussion about introducing config options has many sides. For example in a similar fashion some asked "I want to change all chunking logic", eg how Next.js decides commons etc. instead we ended up implementing #7631 and now soon all users will profit from this. Furthermore it increases the surface of what users have to learn to be able to start getting productive. For example nextjs.org/learn is part of many companies' onboarding process. |
This comment has been minimized.
This comment has been minimized.
If you found this, while looking for a solution, there is now a fork that allows you to set a custom pages directory, you can find a link in this discussion post: #23640 |
Another situation where this would be desirable would be when you're targeting environments where no SSR is available, like native apps with something like capacitor, if you want to have both SSR for the browser and client side loaded content you have to do some really dirty hacks around moving the pages directory which could all be solved if we just had a build time option to select where to take the pages from, please reconsider. |
This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Relating to #875, willing to try a PR if offered guidance.
We're building a ecommerce store from scratch with next and are close to finishing the initial architecture. The only thing bugging us is the number of folders we ended up with. The
src
folder would be a major improvement in our structure and the way we thought it could be done is by adding a property calledpagesDir
in thenext.config.js
configuration.With this new options set to something like:
we could keep all the source code in src, including the pages.
Expected Behavior
Added description at the top of the page
Current Behavior
Pages cannot be placed within a sub folder.
Steps to Reproduce (for bugs)
Context
Your Environment
The text was updated successfully, but these errors were encountered: