Inquiry About Upcoming Features and Timeline

[tanujs95]

Hi there,

First of all, I’d like to express my appreciation for the work on this project. I’ve explored several OTA packages, and I must say, this one stands out as the most mature and user-friendly solution. The integration process has been seamless, and I’m genuinely impressed with its functionality.

With CodePush retiring, we’re planning to adopt this package for our production app. However, I had a couple of questions before proceeding:

1. Do you have an estimated timeline for releasing the S3 and self-hosted deployment guidelines?

2. Are there any plans to introduce support for multiple environments within an app (e.g., QA, Staging, and Production)?
   

3. How to build and deploy the console independently to manage the updates ?
   

Thank you for your time and for maintaining such a great project. Looking forward to your response!

[gronxb]

Hi there,

First of all, I really appreciate your interest in this project!

Now, let me address your questions:

1. AWS Guidelines
I’ve started working on the S3 + Lambda@Edge integration, and development is currently in progress. However, since I’m not a full-time open-source developer and have a full-time job, the development speed might be slower than expected due to limited resources. I estimate that it will take about a week, but no matter what, I aim to release it within this month.

2. Standalone Guidelines

The standalone version requires a plugin. However, since my progress has been slow, contributors have been helping out through a pull request. The discussion is ongoing #83

Once the plugin is released, I will publish the API specs and provide guidance on implementing the API. That should be sufficient, but I also need to consider how to integrate the implementation guide seamlessly into the documentation to make it as easy as possible.

3. Support for Multiple Environments (QA, Staging, Production, etc.)
While there isn’t a built-in feature for multiple environments yet, you can achieve this by setting up multiple environment configurations. For example, you can run hot-updater init twice to create separate environment files and then use dotenv in hot-updater.config.ts to switch between environments as needed. There isn’t an official guide for this yet, but the setup shouldn’t be too difficult.

4. Deployment of the Update Management Console
This is a particularly challenging issue. I’ve thought a lot about it, but since my priority was releasing the library itself, I had to postpone working on a deployment solution for the console. Currently, the console only works on localhost, similar to Storybook, which avoids security concerns. The reason this is difficult is that while simply deploying it would be easy, the console is connected to the database and supports rollback functionality. This means authentication (e.g., GitHub OAuth, Google Login) needs to be implemented before allowing access to the console. Right now, my priority is supporting more hosting providers, and once that’s in a good place, I plan to focus on improving and deploying the console. Eventually, deploying the console is something that must be done.

I really appreciate your patience and support! Let me know if you have any other questions.

[ShaunLWM]

@tanujs95

For your question 2, I am doing something similar (something quick and hacky)

import { config } from "dotenv";

import path from "path";

const envFile = `.env.${process.env.NODE_ENV || "development"}`;
config({ path: path.resolve(process.cwd(), envFile) });

this will properly load your env variables based on your NODE_ENV when running your app.