search

activist-org / activist

An open-source activism platform
https://activist.org
GNU Affero General Public License v3.0
225 stars 185 forks source link

Make all frontend dependencies explicit version numbers rather than minimums #872

Closed andrewtavis closed 1 month ago

andrewtavis commented 5 months ago

Terms

Description

The way that we've been doing frontend dependencies for the longest time is to have a minimum version number and let yarn figure out the rest. An issue with this is that it's making maintaining PRs for the frontend dramatically more difficult, as each time there's an added dependency we also get minor version updates that lead to overly complex merge conflicts with yarn.lock. With this in mind, it'd be great to have only explicit version numbers for the frontend in the pageage.json file.

We can set all current minimums as the explicit version number and work it out until we have a working build, and then from there we can update them regularly as needed :)

Note - related issues are:

Contribution

Happy to support or work on this myself eventually! 😊

andrewtavis commented 5 months ago

CC @aasimsyed again :) Thanks for the chats on dependencies and for your work on that there yarn.lock! Let's try to have you not need to do that again :)

andrewtavis commented 5 months ago

One thing that's needed from here is also removing all of the packages that we don't need except to suppress the warnings :)

tasawar-hussain commented 5 months ago

I would like to take it up!

andrewtavis commented 5 months ago

Hey @tasawar-hussain 👋 Thanks for the interest! We talked yesterday that @aasimsyed was going to take this one, but I'll get you on the other two you wrote in :)

andrewtavis commented 5 months ago

@aasimsyed, can you write in here and I'll assign?

arescrimson commented 1 month ago

Hey Andrew! Was this related to the issue that came up earlier this year when we resolved the bunch of issues that were coming up when building the frontend in Docker? If so, could maybe take a look or assist anyone who's currently working on the issue. Could also look at the related issue #871. Just let me know what your plans are for these issues, etc 😁

andrewtavis commented 1 month ago

Hey @arescrimson! Happy to have you work on this one :) Big thing is just setting up the current dependencies to all be explicit, which might take a bit of trial and error, but I'm sure you'll be able to handle it 😊

Assigning, and great to hear from you!

arescrimson commented 1 month ago

Hey Andrew! So I was basically looking at dependencies and general dos and donts of whether to lock dependences to major/minor versions yesterday. I was wondering if you could give any guidance on what I'm thinking for dependencies to specify explicit versions for, vs maybe leaving some unspecified.

Dependencies to lock:

Large packages, especially ones that can have minor changes that cause headaches like typescript, nuxt, tailwind, vue, etc, I think can be locked safely. I think just the versions in use as of right now are fine?

Dependencies that can remain unlocked:

I think things like dev utility and ui libraries are fine - this would include things like uuid, type libraries, etc.

Let me know if this sounds like the right track. I don't really know how specifically most of these libraries are being used, and if you plan to use any newer features from potential future releases, but I think if non specified dependencies are causing headaches now, and the project as of right now is in a stable stage of development, at least locking the big packages should be a good start. Let me know if this sounds good 😁

andrewtavis commented 1 month ago

All sounds really wonderful, @arescrimson :) Thanks for the research here! Looking forward to locking those we can down! 🔒

arescrimson commented 1 month ago

Oh, and if you want to go for the option of just specifying explicit versions for all the dependencies, I'll start off with that and maybe down the line you can look into reintroducing major/minor changing dependency versions, etc.

andrewtavis commented 1 month ago

Ya I guess let's go full explicit :) Big thing is that we want to be able to locally test the frontend, and there's an external bug that means that we need to reinstall the via yarn. But then when we do that we get all new dependencies and potential merge conflicts, which is a lot to deal with when you just want to see if there's a new TS error...

Thanks for the help, @arescrimson!

andrewtavis commented 1 month ago

Closed by #951 :) Thanks so much for the help here, @arescrimson! Looking forward to easier times fixing TS errors moving forward 😊