Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Compose some site scripts to reduce complexity of
package.json
#189Compose some site scripts to reduce complexity of
package.json
#189Changes from all commits
91e404a
0274cb3
243e95c
bfaa398
f8de754
a3c3a86
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 need to switch to
"type": "module"
inpackage.json
s to upgrade to chalk 5 and execa 6 (they are ESM-only). We can do this when vercel/next.js#33637 is merged and we’ve upgraded Next.js to latest.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 might not be an actual problem, but it seems that
execa
buffersstdout
by default seen here. I am wondering if we are going to hit that limit realistically? Probably not, but worth keeping in mind.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.
Good point! It’s 100MB by default though, so I hope it will be enough 😅
Alternatively, we can launch Next.js server here directly, i.e. in the same process. That would mean that we switched to a custom server though – not sure if it’d be a good thing to do.
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.
Wonder what will happen at the buffer limit. I assume the buffer simply wraps around and still outputs to
stdout
, so perhaps it's a non-issueThere 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.
To help enforce constancy between the logging messages's formatting using
chalk
and use of emojis, what if we create a wrapper function like this:(this could also be simplified to just accepting a single
scriptName: string
argument, and then loggingRunning script ${scriptName}...
,✅ Completed script "${scriptName}"
, etc)This would let developers focus on writing the functionality of the scripts:
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.
Thanks Ben! I tried creating similar abstractions for scripts in some side projects, but found them more costly than beneficial in the end. Imagine we have a script that generates a file and let’s say we don’t want to override the result unless
FORCE=true
is provided. So our messages will look something like:As you can see,
startMsg
andsuccessMsg
vary. File path (/x/y/z
) can vary too if it’s in some configurableDATA_DIR_PATH
directory. This is just one possible scenario of what a script might want to do – the reality will be full of diversity.My current thinking leans towards using standard logging functions plus
chalk
. This is simple, flexible and solid enough. There is not much added repetition and the cost of forgetting to log something is quite small. On the other hand, we don’t need to learn how to use a new wrapper abstraction or add features to it.Here are some example scripts I wrote for a side project: https://github.com/kachkaev/tooling-for-how-old-is-this-house/tree/4e1c420a88fb6c3d75fef17729eeed9c720fadc3/src/scripts. There are tens of them, all ‘wrapper-free’ (and with top-level await already 🤓).
The only abstraction I find useful these days is
ScriptError
. It is 100% like a normalError
, but if a script throws it all the way up, Node does not print the call stack. It’s an alternative to writing this, but with a more familiar syntax.WDYT?
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.
Thanks Alex, that makes sense to me - you're right we shouldn't sacrifice flexibility when abstracting how we log messages in the scripts.
One way to avoid developers from having to worry about usage of
chalk
and emojis could be an abstraction such asScriptError
as you suggest, but I don't feel strongly either-way about this. I'm happy for this to be left as is.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.
Some helper logging lib would be useful indeed! I did a quick research a few months ago, but could not find anything compelling. We don’t expect to handle stdin in scripts, so we don’t need anything interactive like prompts.
If we introduce some third-party util, what we’ll be using at most is some combination of
console.log
+chalk
. I don’t know how much that will help, but I’m happy try out a new lib if anyone has suggestions!