Use separate server.dev.js and server.prod.js files #48
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I used this template as a reference while migrating a Discord bot + Remix v2 app to RRv7, and ran into a couple of odditites because of the assumptions made in this project. I found the single dev/prod entrypoint with dynamic imports impossible to set up with a complex TypeScript project. The way the production server script isn't included in any other part of the build made it tricky to get a daemon up with an appropriate execution context. This splits apart `server.js` into `server.dev.js`/`server.prod.js`, shifts the `app.listen()` call into both files, and sets up HMR/static file hosting as necessary in each environment. I found this allowed me to use a `.js` file at the root of the project, copied into the Docker build, while still starting up all the important functionality in `server/app.ts`. I think this is likely to be a clearer starting point for others in a similar situation. I'm not sure if this is precisely equivalent to the previous implementation, which imported the module for `server/app.ts` within a middleware function on each request. That seemed possibly undesirable (but I'm not sure if it was intended to enable o11y etc).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I used this template as a reference while migrating a Discord bot + Remix v2 app to RRv7, and ran into a couple of odditites because of the assumptions made in this project. I found the single dev/prod entrypoint with dynamic imports impossible to set up with a complex TypeScript project. The way the production server script isn't included in any other part of the build made it tricky to get a daemon up with an appropriate execution context.
This splits apart
server.jsintoserver.dev.js/server.prod.js, shifts theapp.listen()call into both files, and sets up HMR/static file hosting as necessary in each environment. I found this allowed me to use a.jsfile at the root of the project, copied into the Docker build, while still starting up all the important functionality inserver/app.ts. I think this is likely to be a clearer starting point for others in a similar situation.I'm not sure if this is precisely equivalent to the previous implementation, which imported the module for
server/app.tswithin a middleware function on each request. That seemed possibly undesirable (but I'm not sure if it was intended to enable o11y etc).