Proposal: Change priority of script resolution
See original GitHub issueThe debug logs we introduced in v6
helps to identify the problem but there have been numerous issues opened because of the way findBin
works currently. Specifically, many users inadvertently define a script in the package.json which conflicts with the installed linter like prettier
. However, I think having the option to run arbitrary scripts by defining them in the package.json is a useful feature and we shouldn’t drop it. Instead, how about changing the priority such that we look for installed binaries first and check the package scripts only if a binary could not be resolved? This would be a breaking change though.
Issue Analytics
- State:
- Created 6 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Restricting Priority and Resolution
Using Behaviours you can easily restrict priorities and resolution values by project and/or issue type, or anything else such as current user groups...
Read more >Priorities per Project and Resolutions per Issue Type - Jira
I want to be able to specify different priorities for different projects instead of having a global priority list. The current global priority...
Read more >Priority vector re-prioritization proposal #329 - GitHub
This PR introduces a way to dynamically set an interest group's priority and filter them by way of a sparse vector multiplication.
Read more >Set priority for an operational state
On the Operational State Priority page, click the operational state for which you want to set or update priority. Enter a Priority and...
Read more >Unable to change event Priority in EPI script
The Priority Resolver step happens after that EPI step. Therefore, you need to put your script into the next step which is "Before...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I would vote against it since I believe this will introduce not less but probably even more confusion. I actually think that dropping this might be a good idea. Too much magic 🔮 😃
Another benefit is that it will allow people choose which runner to use by writing
yarn task:name
ornpm run task:name
which isn’t the case ATM.Migration path could be a bit of pain but if we can make a nice validation message about it, it would be an easy one I think.
Thoughts?
Was closed in v7