Repository navigation
nodemon (or similar) in core #40429
Description
Activity
I very much prefer https://github.com/fgnass/node-dev to nodemon mostly because nodemon restarts the whole process when it detects a change, whereas node-dev only reloads the single module which changed and it's dependents. On bigger projects this can save quite a lot of overhead.
Reacted by Mohnish Satidasani, hinell, Nick K., Eliaz Bobadilla and Christian@boneskull why do you think it's a different usecase? I use it on typical backend projects interchangeably.
it appears to be for development. but regardless, this issue is about nodemon, which many people use
Are you talking about using nodemon as a tool to restart your server in production?
FYI most people use nodemon just for development. A very tiny minority of users use nodemon for other usecases.
Also this issue is not about nodemon specifically. I understand it as a feature request for a tool to manage code reload for development of long running node.js processes.
I think the author only mentioned nodemon because that is the most commonly used tool for this.Reacted by Liam O'Boyle and Eliaz BobadillaReacted by Cameron TacklindI would like to start that we should look at solving the major use cases, not all possible edge cases with this. I do want this feature very badly.
- This would be ideal to enable the reload devtools workflows that are missing from node's devtools integration.
- This could enable various sane things like file watching causing restarts during development. Though, this could have some loss of data if done too pro-actively so likely needs some kind of config around how to do restarts.
- This could enable a sane path towards supporting
import.meta.hotwhich isn't possible due to ESM cache having no way to safely eject entries in certain scenarios (effect of the ESM spec design). - For "production" I think there are plenty of people using restart managers (nodemon or other) and any restart feature could be used for this purpose to avoid some problems in particular with people wanting to setup Windows Services that restart on exit (staring blankly at my minecraft server in the corner here).
I think determining what restart means (soft vs hard) would be a good first step to figuring out what could be in core. I think if we do want devtools integration that relies on reloads like perf tab to properly work we likely won't be able to just vendor in an existing library though. Also, node can likely spin up a much smaller footprint manager than a full blown JS VM.
I don't think bickering about gritty details and if something is the best solution needs to be done at the investigation phase of this. I think there will generally be more specialized solutions that people can use if whatever node ships doesn't fit their specific need. We are trying to help users and if we don't ship anything due to bickering, we don't improve the situation for anyone.
Reacted by Matteo CollinaI think there will generally be more specialized solutions that people can use if whatever node ships doesn't fit their specific need.
This feature request seems like one of those things that can be very opinionated, which makes me lean towards -1 for inclusion in node core. However, I suppose at the very least if it's possible to build/install node without whatever tool, I would be more ok with it. I already use (other) 3rd party tools for managing node processes and don't want to add more bloat to my node installations.
@mscdex I'm not sure preventing every kilobyte of unused core is really a goal of Node. Providing use cases to users is paramount and various things like existing devtools workflows that are currently disabled in the node inspector need some kind of internal reload manager. We for example ship
acornwhich is not used outside of the REPL. We also have websockets implementation for the inspector but never expose it either. Fighting to avoid adding any features that won't be used in all cases is tantamount to ripping out most of core so node is not usable on its own and all features must be bespoke and from the ecosystem.Reacted by Jiri SpacWe for example ship
acornwhich is not used outside of the REPL. We also have websockets implementation for the inspector but never expose it either.We don't already include nodemon, so these examples aren't quite the same. Besides, as far as I understand it, in the case of acorn and websockets both were more or less required. nodemon is not required to fix an issue or compatibility problem that currently exists in node core itself.
Fighting to avoid adding any features that won't be used in all cases is tantamount to ripping out most of core so node is not usable on its own and all features must be bespoke and from the ecosystem.
That's a bit extreme. We've already had this small core discussion many times in the past, so I'm not going to repeat it here. However, I don't think there is anything wrong with wanting a small(er) node core (not just in literal size but also in scope) and not wanting to throw in the kitchen sink.
I tend to agree we need something to solve this problem. I don't think we should be embedding nodemon - that's a solved problem at this point, I don't think we would stop people from using nodemon. I would like something better than nodemon.
However the hot reloading within devtools and
import.meta.hotare important and currently impossible for us to solve for ESM.Reacted by Michaël Zasso, Jiri Spac, Tierney Cyren and Ian Sutherlandimpossible for us to solve for ESM
due to some limitations in the current node ESM loader implementation?
due to some limitations in the current node ESM loader implementation?
As far as I know it's currently impossible to implement hot module reloading in ESM.
due to some limitations in the current node ESM loader implementation?
No. This is due to how caching is constrained by the specification, once a URL is used it is permanently cached and cannot be unloaded.
Besides, as far as I understand it, in the case of acorn and websockets both were more or less required.
In both cases there is no requirement that node support users wishing to use the features these provide.
46 remaining items
- added 2 commits that reference this issue
on Jan 3, 2023
Is your feature request related to a problem? Please describe.
Not particularly. It's related to a problem in that it is proposing the addition or inclusion of a tool that is widely used for a common problem.
Describe the solution you'd like
I recently put out a tweet from @nodejs on Twitter asking folks what tool they find most useful day-to-day. I generally try to do this not with the intent to bring a proposal or something like that, but to have some engaging activity that could be helpful to someone somewhere.
One thing I noticed was just how many people replied with "nodemon". It seemed to come up just as often as DevTools, VS Code, and TypeScript which I found remarkable.
I'd like to recommend that we consider either vendoring nodemon or explore writing a nodemon-like from scratch in core.
Describe alternatives you've considered
Doing nothing, which would be fine. This is a problem that is obviously solvable in userland, but one that people clearly need solved. If the result of this issue is "this should be in userland" that's totally fine.