-
Notifications
You must be signed in to change notification settings - Fork 21
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
Add postinstall script to readme #65
Conversation
Thanks! |
Glad to help, thanks for the merge! |
This might be obvious to experienced npm users, but it wasn't to me: After some research, I found there is no good solution to this. The only way to get something to run after |
Good point, sorry about this. I looked around a bit, and it seems this is known behavior of Yarn does it correctly (runs Since it would be a while before any change, and npm run i <pkg> Even nicer if typesync install <pkg name> or just: typesync <pkg name> and then it would handle the installation, like |
karlhorky, I agree with your assessment of the automation scripting. If only everyone could switch to yarn ... Regarding |
@mike-clark-8192 that workflow sounds like |
Use-cases for typesync (npm assumed):
The dream of the package.json "postinstall" script was that you could simplify all three of these scenarios (assuming you had added the the postinstall script to your project's package.json ahead of time):
I believe all three work under yarn(? I'm not a yarn guy, haven't tested), but the third case, which offers the most savings, doesn't work under npm because npm doesn't run postinstall after installing a new package. Also, the npm devs have said they never will change this 'quirk' (their term) of postinstall. If you want to ignore the postinstall idea altogether and mix in the usage of
However, I think there was some hope that maybe the typesync maintainers might be interested in implementing everything a lazy njs/npm/ts dev could ever want :):
I might actually look into this myself some day, but I have several weeks of work piled up, so I'll check back in when I free up. Thanks! |
If I were to add this, would the My concern is having to parse arguments like |
Ha! Good catch. I hadn't thought of that. I'm not gonna lie, this will be a little messy to implement, but I think users will love it. I'll type up some notes and reply in a bit. |
Additional CLI user interface
Implementation notesInvoking the package managerSee the cli --help above for info on guessing the user's package manager (and the ability to override the guess). NPM (and probably yarn) programmatic APIs aren't stable. Their CLI is their stable interface, so child_process.exec is probably the only way to do this that isn't an impossible versioning nightmare. We have to programmatically construct the correct command to issue to the PM, but this is relatively easy. Relaying package manager output back to the userWe must capture stdout and stderr from exec(), then write it back to typesync's stderr + stdout. We don't need to interpret/parse the output because the process exit code (available from exec) will tell us success vs. failure, which is all we need to branch on. Crazy npm arg parsing and infrequently used options
The typed-install projectThe typed-install ( Does typesync even need it?typesync is fully functional as it is right now, and maybe the extra bit of convenience added by the above (plus the presence of already-existing complimentary tools) isn't worth complicating the project with. Anyway, it was fun to talk about, so no loss if it isn't a good fit. Cheers! :) |
Thanks for the detailed write-up! I don't currently have a lot of free time to work on these things, however. And I guess I just don't install new packages often enough for this to bother me. 😅 |
There has been a bit of movement on this point actually - I submitted an npm RFC and the npm maintainers commented that there is a valid use case there and that they want to do something about this (maybe even a new feature with a new name that allows for this workflow). |
I think there would be a simple way to do it, if @jeffijoe would be up for it. Don't worry about all of the arguments - keeping up with the package managers is not going to be a good time. Just pass all of them over to the package manager and let it handle them (the user should know which arguments they can use and how). One possible exception - a So eg.
would just get translated to:
Or, if they use Yarn:
would just get translated to:
One special feature (but also pretty simple to implement) would be to install
becomes:
|
@karlhorky it sounds like jeffijoe has enough work on his plate without having to worry about integrating with package mangers via exec(). Entirely from an end-user's perspective, I feel the feature is a natural fit for what some end-users want to get out of typesync. However, from a technical perspective, the package-manager integration "subsystem" is an entirely different beast from typesync's core functionality -- which is syncing types in the package descriptor. I think I might try to prototype a meta-module that integrates the functionality of typesync and typedi into a single seamless CLI interface. I'll invite you to the repo when I set it up! |
Closes #63