Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set default nodeJS 18.18.0 #441

Open
carlosferrerdev opened this issue Sep 16, 2023 · 13 comments
Open

Set default nodeJS 18.18.0 #441

carlosferrerdev opened this issue Sep 16, 2023 · 13 comments
Assignees

Comments

@carlosferrerdev
Copy link
Contributor

carlosferrerdev commented Sep 16, 2023

On September 11, 2023, NodeJS 16 was discontinued and will no longer receive support or security updates.

Update the kitt material to install the latest stable LTS version of NodeJS, which is version 18.18.0

@carlosferrerdev carlosferrerdev changed the title Set default nodeJS 18.17.1 Set default nodeJS 18.18.0 Sep 22, 2023
@ajdubovoy
Copy link
Contributor

@Eschults I don't think updating node would be a bad idea at all. In terms of technically doing it in the setup guide, it'd be quite easy. But how do you feel about us doing such an update?

@Eschults
Copy link
Member

Eschults commented Jan 31, 2024

Hello @ajdubovoy 👋

We definitely should, the recommended LTS version is now 20, let's take the opportunity bump ruby to 3.2.3 at the same time (last version bump was handled in #391). Let's prepare the PRs to plan a release before Q2 batches start 👌

Besides challenges, this change impacts a lot of boilerplates / livecodes repositories, both in the @lewagon org and in the @lewagon-assess org for the French certification exam.

Let's start by creating PR using the same branch name convention for all repos, and we can decide later how we plan to release the change 🚀

@ajdubovoy
Copy link
Contributor

Sounds good! But also sounds like quite a huge project unless I'm misunderstanding. I'm happy to take it on, but is there any sense in us coming up with a strategy beforehand? Or is it better if I just dive into all the repos and see if anything breaks when I upgrade....?

@ajdubovoy
Copy link
Contributor

Also I don't think I have access to @lewagon-assess

@Eschults
Copy link
Member

Sounds good! But also sounds like quite a huge project unless I'm misunderstanding. I'm happy to take it on, but is there any sense in us coming up with a strategy beforehand? Or is it better if I just dive into all the repos and see if anything breaks when I upgrade....?

Let's start by identifying the repos that need a change in the .rubyversion / Gemfile and prepare the PRs, this is a repetitive task that could easily be delegated, there shouldn't be any breaking changes due to the ruby bump so I don't think we need to thoroughly test every repo, maybe we can spend some time on the ones w/ more JavaScript dependencies but it could be quite straightforward if we don't need to change any packages 🤞

✅ I granted you access to @lewagon-assess

@ajdubovoy
Copy link
Contributor

ajdubovoy commented Jan 31, 2024

Sounds good. Hm, yeah I doubt the JS update will break anything tbh since the students barely use node anymore. I'd be more concerned about the Ruby one, but it's fortunately a smaller update.

Thank you!

@ajdubovoy ajdubovoy self-assigned this Jan 31, 2024
@ajdubovoy
Copy link
Contributor

@nguiban just looping you in here as well 🚀

@nguiban
Copy link

nguiban commented Feb 7, 2024

Hello !
I was looking at the roadmap for web dev. In March, we're going to struggle a bit to plan that, but would it be a good idea to schedule it for May-June before the July batches?

@ajdubovoy
Copy link
Contributor

Also works for me! Nothing is breaking because of this, it's just maintenance we need to eventually do

@wJoenn
Copy link

wJoenn commented Feb 20, 2024

@ajdubovoy @Eschults Just a heads up that but Webpack 4 is not compatible with Node 17+ because Node has migrated to OpenSSL3 but it still relies on legacy ssl protocols.

It's still possible to use a webpack 4 command by exporting the NODE_OPTIONS=--openssl-legacy-provider ENV var before running the command but at this point you should really consider moving on from Webpack 4 which has been EOLed for a few years already.

Back in my by batch we had a couple slides about how Webpack is the industry standard and that's why LeWagon is still sticking to it (if that's still what you want then bump to v5) but as far as frontend development goes Vite has really become the golden standard in any project that can use it. It's also easier to setup for you and easier to understand for the students so imo LeWagon should drop Webpack completely (which you have already done for Rails after switching to importmaps) and go with Vite instead if a bundler is still needed at all

@ajdubovoy
Copy link
Contributor

Hi @wJoenn as far as I'm aware we've fully dropped Webpack from the curriculum already and use no-build setups in the entire front end unit and in Rails 😊

@wJoenn
Copy link

wJoenn commented Feb 21, 2024

It's still inside the frontend unit's package.json
https://github.com/lewagon/fullstack-challenges/blob/master/04-Front-End/package.json

@ajdubovoy
Copy link
Contributor

We could probably remove it because it's never used in a challenge

@ajdubovoy ajdubovoy reopened this Feb 28, 2024
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

No branches or pull requests

5 participants