Automatically detect if dev server is running

[vabene1111]

I maintain an open source project utilising django and vue. Currently on vue2 I use webpack with webpack bundle tracker. While migrating to Vue3 I am thinking about switching to vite and django-vite as it seems to work a lot better. I just have one inconvenience.

I would be happy to contribute a fix/improvement if that is wanted.

Problem

Switching between testing on with dev server / HMR is cumbersome because you need to change settings/environments

Solution

add an app specific setting autodetect_dev_server (or similar)

in asset_load.py when generating the ws_client check if the setting is enabled and detect if the dev server is running

    def generate_vite_ws_client(self, **kwargs: Dict[str, str]) -> str:

        if self.autodetect_dev_mode:
            with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
                s.settimeout(0.001)
                try:
                    # check if a service is running on the dev server host/port
                    s.connect((self.dev_server_host, self.dev_server_port))
                    self.dev_mode = True
                except:
                    pass
        
        if not self.dev_mode:
            return ""
        
        url = self._get_dev_server_url(self.ws_client_url)

        return TagGenerator.script(
            url,
            attrs={"type": "module", **kwargs},
        )

This code is just a rough first idea, you know your codebase best so if a different method (e.g. maybe the constructor) is more fitting for running this check and deciding if dev mode should be enabled or not is better feel free to give feedback.

Considerations

This will add a minor delay (in my tests 20-30ms) into the page load but only while DEBUG and autodetect is enabled. Since you don't reload often when using HMR the impact will be insignificant. The setting can be enabled on all dev workspaces and disabled by default, this way you don't have to change it all the time

Other options

1. right now I have a small script in settings.py that checks if the dev server is running and changes the setting accordingly. The problem here is that if you start django before starting vite it wont detect the server at load time.
2. you could configure different environments, but that is additional setup work for each workstation

Invalid options

• just using DEBUG because every now and then you might want to turn on debug on production to generate a quick report or investigate an issue and that would break the page if no dev server is present

Thank you for the great project, I already use it for a smaller project and really like how well it works

[Niicck]

Thank you for your interest in the project and your thoughtful proposal. I took some time to consider it and here are my thoughts.

Switching between testing on with dev server / HMR is cumbersome because you need to change settings/environments

Yes, toggling the "dev_mode" setting is a required step to switch between dev_mode being on and off. I'll get into why this added step can be beneficial, but right off the bat you might be served by setting it to an environment variable that you can quickly change in your own .env file. It can be it's own explicit variable -- is doesn't necessarily need to be bound to DEBUG:

DJANGO_VITE = {
    "default": {
        "dev_mode": os.environ.get("DJANGO_VITE_DEV_MODE", False),
        "static_url_prefix": os.environ.get("DEFAULT_STATIC_URL_PREFIX"),
        "dev_server_port": os.environ.get("DEFAULT_DEV_SERVER_PORT"),
    },

Toggling dev_modes via environment variables in settings is a best practice. I could only see this step being cumbersome if someone were theoretically switching between dev_mode and production_mode very frequently, and even then you'd still have to manually run vite build between switches to run your app in production mode.

dev_mode is not something that I would want to automate. Yes, it is an additional configuration step to define. But following the Zen of Python principle "Explicit is better than implicit," I want developers to have complete control and understanding of when their application is engaged in dev_mode or not. If their vite dev server is not running and they've set dev_mode=True, I want the library to let them know, not silently fallback to an old compiled production build. If a vite server (or any other service using the same port) happens to be running at the same time, I don't to silently force applications to run with dev_mode=True every time. I think introducing this feature would add more complexity than it solves.

just using DEBUG because every now and then you might want to turn on debug on production to generate a quick report or investigate an issue and that would break the page if no dev server is present

I would not recommend turning on django debug mode in production. There are other ways to generate error stack traces that are more secure and less harmful to your app's performance. You can see the same stack traces you'd get with DEBUG=True by writing those error logs to a log file. The Django documentation has some examples on how to do that.

Thank you for your suggestion and support. I'm happy to hear out any other suggestions you'd have to share.

[MrBin99]

Hi, thank you @vabene1111 for your proposal.

I agree with @Niicck, it's very not recommended to turn on DEBUG on production as the Django framework rely on it to be more secure on production an turn off some development tools to be more efficient.

If what you need is stack-traces of errors, in my projects we send 500 errors as emails to the dev team. You could also take a look at tools like Sentry ?

[vabene1111]

Hi, thanks for your feedback. I absolutely agree with your feedback.

I still like the ability to switch automatically, maybe because I am used to this behavior from many years of working with Django webpack plug-in.

Another use case for example is quickly firing up just Django to fix something on the backend without starting vite. So I thought an additional setting that does not change any of the others when not used might be useful.

But all of these things are minor, your reasons and design decisions make perfect sense so feel free to just leave it as is.