-
-
Notifications
You must be signed in to change notification settings - Fork 37
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
automatic merging of next.config.js files #222
Conversation
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.
@roggenkemper I pulled a random example online and it doesn't look like we can handle it, is it expected for this config?
module.exports = {
images: {
domains: [],
},
}
Just jumping in to give some early feedback. From our experience, mucking with the AST is super super fragile. If I were to tackle this I would probably look into some more robust (but uglier) solutions first. We could even change the signature and functionality of |
@lforst What kinds of robust solutions are you thinking of? We are open to ideas. That being said, I think this approach could do the job. Just need to write about ~10 unit tests to cover different formats that we commonly see and I think this will work 50-90% of the time. Even if we can't make this work 100% of the time...anything better than 0% is an improvement over today. |
made some updates based off the conversation with Luca - the flow now is to not deal with AST's, but instead essentially copy over their original config, but add in the call with withSentryConfig which will be updated (getsentry/sentry-javascript#6721) to allow us to add in the Sentry options that we need to add into their config. |
'Please merge those files.', | ||
); | ||
nl(); | ||
if (templateFile === '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.
the config file could also be .ts
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.
is this an edge case that needs to be handled? it seems rare and currently we would create a next.config.js file that they would be able to merge.
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.
Let's get someone from SDK's to approve but looks good from my end
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.
Nothing major but definitely some stuff to adress before we release this.
lib/Helper/MergeConfig.ts
Outdated
const templateFile = fs.readFileSync(templatePath, 'utf8'); | ||
const sourceFile = fs.readFileSync(sourcePath, 'utf8'); | ||
const newText = templateFile.replace('// ORIGINAL CONFIG', sourceFile); | ||
new Function(newText); // check if the file is valid javascript |
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 don't think this will throw if you pass in invalid JS. I would just remove this line.
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.
In my tests, it seems to work as I intended (if there is a syntax error then it will throw an error and the function will return false) . I think eval would achieve the same thing. @scefali mentioned wanting to have some kind of syntax check here
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.
Ah you're right. I messed up how I verified this. Sorry about that!
): Promise<void> { | ||
// if no next.config.js exists, we'll create one | ||
if (!fs.existsSync(destinationPath)) { | ||
fs.copyFileSync(templatePath, destinationPath); |
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.
The written file is gonna be a bit ugly because of the // ORIGINAL CONFIG
comment. Can we either replace it with something a little more instructive or remove it before writing it to disk?
We should probably replace it even with
module.exports = {
// Your Next.js configuration here
}
or smth like 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.
If no next.config.js exists, then it will use the existing next.config.js
template instead of the new one with the // ORIGINAL CONFIG
line.
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.
Ah you're right. I hope this isn't just me but to me the entire logic of this file is super hard to get behind. We should def clean this up some time (not your code but the one that existed before - it probably just grew over time).
This pr adds in automatic merging of the next.config.js files. If there is no existing next.config.js file, then we will add the existing default next.config.js file in. If we are able to merge Sentry's with the existing, then the file will be updated (with the original saved as next.config.original.js). If we are unable to merge, we will create a template file and ask them to merge (the status quo approach) .