-
Notifications
You must be signed in to change notification settings - Fork 244
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
RFC for dependencies change script addition #34
base: main
Are you sure you want to change the base?
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.
Hey! Thanks for this RFC. The team is really excited about having something like this, and we think it's a great idea!
I've added some comments as far as making this feel more idiomatic/appropriate for the CLI, and some clues about specifics about when they should be run (an important detail to include).
Once those changes are in place, I think this is safe to just ratify! It should be relatively low-effort to implement, too!
|
||
## Detailed Explanation | ||
|
||
I think one way this could be backwards compatible is by adding a `postChange` |
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 this should be a lifecycle called change
, where prechange
runs when we've determined changes will be needed, but no tree changes have been applied, and then change
and postchange
would be run after the tree itself gets updated (these should both run after postinstall
).
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 would certainly like to be able to have a prechange
and postchange
!
What would be the difference be between a change
and a postchange
, though?
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.
Likely none, that both exist is more of an artifact of how our lifecycle scripts work. (This is the case with most lifecycle scripts.) In a perfect world, I would only call the non pre/post named lifecycle if it was replacing the action taken at that point, but given the history, keeping things consistent seems better even if it's a little odd to have two lifecycles that do the same thing.
|
||
I currently don't know of any alternative way to do this. I looked around and | ||
found a few different questions trying to do this, but no workarounds or | ||
solutions. |
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 possible using hooks, but it's nowhere near as convenient.
|
||
_(I'm not very familiar with the npm codebase, if there is interest in this RFC | ||
I'd love to dive in to find out these details)_ | ||
|
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.
You can remove this section. We've been talking about getting rid of it for a while.
|
||
## Unresolved Questions and Bikeshedding | ||
|
||
There may be a more self-explanatory name than `postChange` |
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.
See about about change
.
Rendered