Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd `err` and/or `opts` to the no-param-reassign exclusions? #1812
Comments
tunnckoCore
changed the title
|
Actually, for the function foo(opts) {
opts = Object.assign({ bar: true }, opts)
}Mostly, to workaround that i use both function foo(options) {
const opts = Object.assign({ bar: true }, options)
}So at least add |
|
Options should never be mutated, since other things might be using that object. Can you explain why you’d need to mutate or reassign |
|
Yea, agree for the options. As about the error. I'm not reassigning it as a whole, i'm adding a bit more info to it and throwing it again. I explained why i want to add property like const app = {
/**
* Start the magic. Parse input commands and flags,
* give them the corresponding command and its action function.
*
* @returns {Promise}
* @public
* @async
*/
async listen() {
const result = prog.parse(process.argv, opts);
const { args, name, handler } = result;
try {
return handler(...args);
} catch (err) {
err.commandArgv = args[args.length - 1]; // last one is process.argv
err.commandArgs = args;
err.commandName = name;
throw err;
}
},
}and in the CLI listen()
.then(() => {
// this is CLI file.
// eslint-disable-next-line unicorn/no-process-exit
process.exit(0);
})
.catch((err) => {
console.error('Error task:', err.commandName);
if (err.commandArgv && !err.commandArgv['show-stack']) {
console.error('Error message:', err.name, err.message);
} else {
console.error('Error stack:', err.stack);
}
// this is CLI file.
// eslint-disable-next-line unicorn/no-process-exit
process.exit(1);
}); |
|
Do you actually need the stack trace from the original error? If not, it seems like it'd be better to make a new Error instance; either way, you can do |
Exposing that to third party, so it depends.
Ahhh, sweet! How i forgot about that? |
Hey there.
Most frequent i have problem with this rule. And specifically in cases of
options,optsanderr. I also seen in #1089 that this rules is disabled for different reasons. What's your thoughts? Could you consider addingoptsanderr?I know that there is a bit better and more proper way for adding to the error instance, for example creating whole new error class based on the original one. But there is simple things like adding some single metadata property.
In my case such metadata is
err.commandArgvanderr.commandNamewherecommandNameisn't exactly the terminal/unix one, but command of some cli - for examplemycli hellosoerr.commandNamewill behelloregardless what that command does.