Skip to content

Conversation

nandastone
Copy link
Contributor

@nandastone nandastone commented Dec 8, 2021

Developing on the webpack-dev-server required a manual hard reload after every automatic hot-load. If this wasn't done, the service worker would serve the HTML + assets that were built when the dev server first started, without any recent changes.

This MR:

  • Adds a .env setting DISABLE_SERVICE_WORKER=false to disable the service worker. We could also disable the service worker in development mode, but it's useful to be able to test the service worker.
  • Adds .env into .gitignore and creates .env.example. This allows a developer to set .env without the worry of accidentally committing their local environment settings.

@nandastone
Copy link
Contributor Author

@DreadKnight What changes are needed to copy .env.example -> .env as part of the deployment pipeline? .env will no longer be in the repo.

@DreadKnight
Copy link
Member

@nandastone I've configured both Heroku and GitHub pages to use our .env variables (minus the quotes, gotta see if that's ok), so we could get rid of .env and test. We could have the .env.example in the repo just for the kicks, but deployment pipeline is not my specialty. As I see it, that would be kinda redundant because the file will not be properly configured anyway or overwritten.

@DreadKnight
Copy link
Member

DreadKnight commented Dec 8, 2021

So we would have the .env.example properly configured with our secrets in this scenario resulting in people simply connecting to the online multiplayer server with possibly test clients to do tests, which is a bit messy. Guess with time will either have to configure some online multiplayer server deployment just for testing stuff or have some documentation and way for coders to easily set-up their own server (online or locally) based on the specs needed for the project. Stable server .env can pose a security risk if in repo.

@gitpod-io
Copy link

gitpod-io bot commented Dec 8, 2021

@nandastone
Copy link
Contributor Author

Good question. The codebase already has a .env with secrets (https://github.com/nandastone/AncientBeast/blob/master/.env), so test clients are already connecting to the multiplayer server.

You'll need to:

  1. Rotate the security key on the online.ancientbeast.com server.
  2. Remove authentication details from the new .env.example.
  3. Add doco explaining the multiplayer server is not currently available for local development.

@DreadKnight
Copy link
Member

Good question. The codebase already has a .env with secrets (https://github.com/nandastone/AncientBeast/blob/master/.env), so test clients are already connecting to the multiplayer server.

You'll need to:

  1. Rotate the security key on the online.ancientbeast.com server.
  2. Remove authentication details from the new .env.example.
  3. Add doco explaining the multiplayer server is not currently available for local development.

It's there for now because it wasn't ignored so far. But it's really fine to have it for now, makes getting into development easier.

@DreadKnight
Copy link
Member

Updated variables. Usually what I do in these type of situations is simply use .env.example file (pointing to the official server for now and later on to a test server) just in case a custom .env file is missing, so we got defaults. Can you write a condition for that?

As a side note related to this: Earlier I did found some env related npm package plus nice guide, which allowed to define a lot of configs within a file and pick between those easily (guess multiple servers at some point if needed).

@nandastone
Copy link
Contributor Author

@DreadKnight This MR already has a .env.example file (https://github.com/FreezingMoon/AncientBeast/pull/1942/files#diff-a3046da0d15a27e89f2afe639b25748a7ad4d9290af3e7b1b6c1a5533c8f0a8c) and I updated CONTRIBUTING.md to mention this during the installation step.

Is that what you meant?

@DreadKnight
Copy link
Member

@nandastone What I mean is for that to be more than just a placeholder file, to actually be read by the project if .env is missing.

@DreadKnight
Copy link
Member

DreadKnight commented Dec 9, 2021

I've did things like that even for this project and it's way more efficient. We'll just avoid copying .env.example to .env as part of the pipeline and also avoid including command about doing it manually as part of the Contributing.md documentation, simpler.

@@ -1,8 +1,13 @@
import { Client } from '@heroiclabs/nakama-js/dist/nakama-js.esm';
import { Client } from '@heroiclabs/nakama-js';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, interesting.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It resolves to the same file, just feels safer this way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's nice. Back when we started using Nakama, the JS version was super broken and unmaintained overall, so we bumped into so many issues with it. Their NPM package was exploding in popularity, though the devs were kinda "meh, patches welcome".

@DreadKnight
Copy link
Member

DreadKnight commented Dec 9, 2021

Usually was using the "JS if else conditional operator shortcut" when trying to fetch all them .env variables, but since dotenv is being used now, that probably makes things bit trickier for me at least, so my guess is that the "Config" from this page here https://www.npmjs.com/package/dotenv could be used, so in case it gets error, it simply tries to read .env.example instead.

@nandastone
Copy link
Contributor Author

@DreadKnight I've installed dotenv-defaults which works as you've described. If .env exists then its settings are used, otherwise fallback to .env.example.

@DreadKnight
Copy link
Member

@DreadKnight I've installed dotenv-defaults which works as you've described. If .env exists then its settings are used, otherwise fallback to .env.example.

Woot! Good find, this is nice and useful 👍🏻
Just a matter of time this week until I start testing this in action, hopefully it will all go well.

@DreadKnight
Copy link
Member

@nandastone Seems there's a conflict, kinda confusing to fix it myself from GH's UI. Please tweak and I'll merge right away.

* master: (39 commits)
  Comment tweak
  Fix disable materialization sickness power
  Make it easier to read tooltips
  Fix close icon
  capitalization
  Improve vertical position of reset button
  Improve preview creature summoning with "disable sickness"
  Meta Powers persist  by default
  Prevent Tentacle bush from stacking on attacker
  Remove damage and apply effect directly
  Tidying some things
  Suppress double log
  Change tentacle bush to "apply on end of phase" effect.
  Comment tweak
  Tweak Nutcase to match impaler
  Tweak
  Fix impaler movement drop
  Fix nutcase swap death
  Fix linting issue
  Tweaks
  ...

# Conflicts:
#	package-lock.json
@nandastone
Copy link
Contributor Author

@nandastone Seems there's a conflict, kinda confusing to fix it myself from GH's UI. Please tweak and I'll merge right away.

Fixed merge conflict, it was just package-lock.json.

@DreadKnight DreadKnight merged commit d5f7f3f into FreezingMoon:master Dec 13, 2021
@DreadKnight
Copy link
Member

@nandastone Seems there's a conflict, kinda confusing to fix it myself from GH's UI. Please tweak and I'll merge right away.

Fixed merge conflict, it was just package-lock.json.

I'm aware, but at times finding the GH's way of dealing with conflicts ultra confusing, it's too asci and rather cryptic unless I put a lot of time figuring stuff out. Glad that you managed way easier :)

@nandastone nandastone deleted the disable-service-worker-dev branch December 13, 2021 22:15
CyberBishop pushed a commit to CyberBishop/AncientBeast that referenced this pull request Apr 20, 2023
…worker-dev

Disable caching service worker via .env
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants