-
Notifications
You must be signed in to change notification settings - Fork 27k
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
Exploration of different config + expose webpack config #222
Conversation
Disclaimer: I am not a JS developer, so I am not familiar with the traditions in JS world. Config files in JS enable great flexibility, but at a cost of greater complexity and potential misuse and errors. In Python (which is my preferred language), it is common to use config files written in Python. Overall, I like this idea. |
} else { | ||
throw err | ||
} | ||
} | ||
|
||
// no try-cache, it must be a valid json | ||
const config = JSON.parse(data).next || {} | ||
const config = module.default || module || {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, the above comment is irrelevant for the updated implementation.
This is a pretty great idea I think |
If this one get merged (and I hope it will), should this fall back to the old behaviour, so this is not a breaking change? |
@Florian-R You mean also read |
@Florian-R There existed only one config option: |
@frol You're right I missed that, don't know why I was sure there was others options. This indeed shouldn't break any code, dismiss my previous comments. |
This PR now also includes #174 |
@@ -171,4 +172,7 @@ export default async function createCompiler (dir, { hotReload = false } = {}) { | |||
return interpolateNames.get(this.resourcePath) || url | |||
} | |||
}) | |||
const config = await getConfig(dir) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this async? i don't see any way for it to be async.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right! That need was removed since we now use require
. Good catch, I'll update the PR.
Important: since this effectively deprecates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CompuIves could you check these suggestion.
After that, we could get ship this PR :)
|
||
let data | ||
let module | ||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's better to do a sync FS check rather doing this.
That's cleaner.
const defaultConfig = { cdn: true } | ||
const defaultConfig = { | ||
cdn: true, | ||
webpack: (cfg, hotReload) => cfg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a pretty good idea if we could log something, when we are using this user supplied webpack config decorator.
So, I suggest to not to define this.
And when we are using this, we can check for webpack decorator and log it.
@@ -171,4 +172,7 @@ export default async function createCompiler (dir, { hotReload = false } = {}) { | |||
return interpolateNames.get(this.resourcePath) || url | |||
} | |||
}) | |||
const config = getConfig(dir) | |||
const userWebpackConfig = config.webpack(webpackConfig, hotReload) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do this only if user provides a webpack decorator.
If there's a one, we should log it so the user know this is happening.
} else { | ||
throw err | ||
} | ||
} | ||
|
||
// no try-cache, it must be a valid json | ||
const config = JSON.parse(data).next || {} | ||
const config = module.default || module || {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We we should also read the package.json
and check for the next config. If it's there, we should get it. (Only the cdn
field).
And if we found it, we need log a message as it's deprecated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, I think
Could we have a variable className on https://github.com/zeit/next.js/blob/master/lib/document.js#L11 in this config too? That would cover #251 |
@arunoda Processed your feedback! @jonaswindey I think we should create a separate PR for that issue so we can put this PR live sooner. |
@jonaswindey @CompuIves the right way to address that is #251 |
It just occurred to me that it might be smart to restart the next process (with the same flags) when this file changes? 🤔 |
Unless, of course, it's tractable to reload everything without a full restart |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is beautiful. We just need some few messages changes. I've added comments for them.
You may also need to rebase again since there are some conflicts.
Also we need to add a section to doc about configuring webpack config. Here's a suggestion for the layout:
- Add sub section about Customizing webpack config.
- Tell about the main goal of this.
- Show a simple example (like importing images directly)
- Then, ask to use this with care. (Since user could broke our default config)
- So show safe operations like adding plugins, aliases, loaders etc.
Also try to keep the doc for this minimal and we can have a full detailed section on the Wiki.
@@ -171,4 +172,10 @@ export default async function createCompiler (dir, { hotReload = false } = {}) { | |||
return interpolateNames.get(this.resourcePath) || url | |||
} | |||
}) | |||
const config = getConfig(dir) | |||
if (config.webpack) { | |||
console.log('Using Webpack config function defined in next.config.js.') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a "> " before the message. Like this:
console.log('> Using Webpack config function defined in next.config.js.')
} | ||
|
||
if (packageConfig) { | ||
console.warn("WARNING: You're using package.json as source of config for next.js. Please use next.config.js instead.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change this to:
console.log("> [warn] You are using package.json for next.js config. Use next.config.js instead.");
Just FYI: Try not to use "Please" in front of messages. It's sounds like commanding.
I tend to use that and one of my UK friend asked to drop that. Messages sounds nice after that :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks for the tip!
@rauchg That's a good point, but it seems like it's hard to do that via webpack itself. We have to do a hard process restart, may be we could do it using the grunt config easily. |
@CompuIves yep. Changes are great. Shall we try @rauchg's suggestion too. |
097febe
to
6c7eaa9
Compare
@arunoda Added config watching, it kills the old child process and start a new one when it sees a change in Also rebased with master! |
I wonder if we should:
export default {
async webpack (webpackConfig, hotReload) {
const newConfig = { ...webpackConfig }
newConfig.something = await getSomething()
return newConfig
}
} |
d6fe625
to
4c8ab59
Compare
Rebased master and did the required changes. I stumbled upon the item of CDN in the FAQ of the README. Do we still need this? |
```javascript | ||
// next.config.js | ||
module.exports = { | ||
cdn: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have a cdn
option. May be we need to re-phrase this.
@@ -423,7 +483,7 @@ For this reason we want to promote a situation where users can share the cache f | |||
|
|||
We are committed to providing a great uptime and levels of security for our CDN. Even so, we also **automatically fall back** if the CDN script fails to load [with a simple trick](http://www.hanselman.com/blog/CDNsFailButYourScriptsDontHaveToFallbackFromCDNToLocalJQuery.aspx). | |||
|
|||
To turn the CDN off, just set `{ “next”: { “cdn”: false } }` in `package.json`. | |||
To turn the CDN off, just set `module.exports = { cdn: false }` in `next.config.js`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't worry about this one. We'll remove it anyway.
@CompuIves I added some comments. |
I'll remove the cdn notes myself |
Thanks @CompuIves |
Awesome! |
Nice! Was great to help! 🎉 |
We currently use
package.json
for our configuration. I think we should move away from usingpackage.json
and use something likenext.config.js
since it gives us more power than JSON.An example is the issue for custom Webpack support: #40.
With a config like this you could do this for example:
Which is in my opinion better than creating a new file for webpack since this is more centralised. This does however still give users the option to use different files, for the webpack example:
These are just my thoughts, I found out that I needed a sort of config file in
.js
when starting a PR for this project. Very curious what others think of this 😄.