Proposal for Simplifying Updates to Old Browser Extension Projects

[Leizhenpeng]

Description:

Problem:

Our repository has been used to develop many browser plugins. However, as the repository is updated, it becomes challenging to apply these updates to older projects. These changes are often extensive and can be disruptive to multiple repositories.

Proposed Solution:

I propose a more efficient update mechanism by publishing packages to npm under the package directory. By treating these as dependencies, we can update the packages more easily. This approach offers several benefits:

1. Simplified Updates: Users only need to update the relevant packages, making the process smoother, especially for older projects.
2. Convenient Template Initialization: We can provide a quick-start template folder, reducing the need for users to install every package in the monorepo. They only need to include the essential configurations and their custom pages.

Benefits:

• User Convenience: Especially beneficial for older projects, users can more easily integrate updates without major disruptions.
• Efficiency: Streamlines the update process, allowing users to focus on essential configurations and customizations.

[Leizhenpeng]

@Jonghakseo

[PatrykKuniczak]

But this is a template, not a package like e.g turbo
This is sth like NextJS you can update Next, but there's difference between template.
New features are available and you don't need to use it, in template you need to download new version and it will be changed your folder structure.

We're creating new folder structure because of new modules and etc.
And this is tricky to implement it to the users, because we don't know what project structure users have(Because they are free to change it for they needs).

And There's so many conflicts, because user decided to remove content and the content is still in the latest version.

When user update it, then this folder return to his project, or if he change names of folders, update is totally unable to do,
because all folders from template will be downloaded to his project, and he/she will have 2 versions of template in 2 project.

In the case of the possibility of this solution, they need to follow only us folder structure, and this need to be defined by us of course, and there's no flexibility for users, and bigger folder structure change will be also hard to implement on user working env, because of the changes in e.g folders name or structure.

I think this update engine could be a monster, because of the files which user have already on his/her project, and if we have other names between version, we're need to create additional script for this migration engine.

This is not that easy, to implement, it will be next complication for this template.

Keep in mind, that's next this which can break down, and we will have next bugs to repair, very hard to reproduce and time-consuming.

But this idea of the separated packages like e.g NestJS have is good idea, and i was talking about that with @Jonghakseo several weeks ago.

Maybe i don't see sth, and it's possible to implement, but i haven't seen it before in other templates.

It's better idea, to create this separated packages, and on the realase description, users can see changes and decide if they want to implement it or don't.

I was thinking about what you've described a year before, but i gave up this because of the complication.

[Leizhenpeng]

Thx , got it ..

[wonkyDD]

If this is achieved, it would be incredibly convenient 👍

[Jonghakseo]

As @PatrykKuniczak said, feature-specific management via npm packages would be a huge benefit, maybe we could separate the abstracted VITE settings, HMR modules, etc. into packages for better update benefits. I think it's a good direction to think about, and I'm planning to open a discord community in August, so we can discuss it further there.

Whatever it is, if it helps people developing Chrome extensions, I think it's worth it. 😄

[PatrykKuniczak]

@Jonghakseo We achived 2k stars on repo, well done for every contributor ❤

[PatrykKuniczak]

I closing this, it will be implemented in the near future.
We will be keeping it in mind, and we will implement in #400 (This attachment have became an notification)