jiebi/CodeConvo huggingface dataset:
Change:
.footer .col-header { padding-bottom: 5px; <ins> padding-left: 5px; </ins> font-weight: bold; } .footer a:not([class*='inline']) { display: block; <ins> padding-left: 5px } .footer a:hover { outline-offset: 1px; outline: 1px dashed #A0A0A0; background-color: #ffbe41; </ins> } .night .footer {

Discussion:
<!-- NOTE: If you're reporting a security issue, don't create a GitHub issue. Instead, email We will look into it immediately. --Describe your problem and how to reproduce it: At the moment, the clickable area of footer links are spanning the full width of their parent div. I'm not sure if this is on purpose, but IMHO, they should fit to their content instead, since a user could get navigated to another page if they accidentally click somewhere within the clickable area. This issue is on , but it is down for maintenance at the moment. The screenshot is of my local fCC. !
Is that actually a problem, though? I think having list items spread like that is pretty common. It could be a problem if you aimed for, say, Learn and got News, but there's a reasonable amount of space between them. How about if the box were subtly highlighted on hover?
Thanks for the threads
Tbh, this is the first time I have seen footer items spread like that, though it is common to me to see that on a navbar. I have no problem with leaving it as is, but adding background color on hover would be great.
I, personally, would prefer if only the text was clickable - but it works either way.
Personally I like the wider boxes, because I'm lazy and click in the general vicinity of things. So, I've a PR for the highlight approach, since that was a really easy fix. If that doesn't seem right we can always shrink the links onto the text.
Change:
This will make it easier for you to work with `rem` units later, as `2rem` would be 20px. <del> Also, set the `box-sizing` property to `border-box`. </del> # --hints-- You should create an `html` selector.

Discussion:
Someone in the forums pointed out that adding the property just to will not have the intended effect since the property is not inherited. It appears to me that removing this property completely from in the final product does not seem to make any difference to the layout. Do we need ? If so, if the intent is to apply it to all elements then it should probably be moved to the rule set. Either remove completely or move it into the ruleset. No response N/A No response
Pretty sure I saw this in another challenge too and it got fixed. The CSS used looks like the of setting the but with the actual inheriting missing from the code. It should be fixed, but I would not suggest we remove , setting that (in my opinion) is pretty much a best pratice.
I'm guessing it would be easier and take less explaining to update step 26 to add the on that selector and then remove the mention of it in step 27. Then update all the seed code.
Just a heads up, if lasjorg PR merged without issue, balance sheet project suffer the same issue, we can open a PR or issue for it, if the PR is merged. Except that the balance sheet project , doesn't do much and moving it break the layout.
Change:
assert.equal(allSongs[2].artist, "Quincy Larson"); ``` <del> The third object in your `allSongs` array should have a `duration` property set to the string `4:15`. </del> <ins> The third object in your `allSongs` array should have a `duration` property set to the string `3:51`. </ins> ```js assert.equal(allSongs[2].duration, "3:51");

Discussion:
The description shows the property should have a value of but the hint shows instead The property should have a value of the string . ! Device: [e.g. iPhone 6, Laptop] OS: [e.g. iOS 14, Windows 10, Ubuntu 20.04] Browser: [e.g. Chrome, Safari] Version: [e.g. 22] No response
Change:
it('returns a boolean', () => { const result = isWhiteListedPath(); expect(typeof result).toBe('boolean'); }); it('returns true for a white listed path', () => { <del> expect.assertions(2); </del> const resultA = isWhiteListedPath( '/auth/auth0/callback?code=yF_mGjswLsef-_RLo', whiteList

Discussion:
These should be available without any access tokens: [x] Used for public profile views. [x] Used for confirming and email. [x] Health Check
Change:
Alternatively you can follow official documentation referenced below: <del> To install and configure Playwright on your machine check out this [documentation](https://playwright.dev/docs/intro#installing-playwright) </del> <ins> To install and configure Playwright on your machine check out this [documentation](https://playwright.dev/docs/intro#installing-playwright). </ins> To learn how to write Playwright tests, or 'specs', please see Playwright's official [documentation](https://playwright.dev/docs/writing-tests).

Discussion:
In the , we say that: But IMHO, test IDs should be used sparingly in cases where we can't use any other locators as an alternative. The issue with test IDs is that it doesn't guarantee the page has the correct text or the page / section of the page has proper element usages (which is important to ensure that our pages are accessible). Here is an example, let's pretend we have the following HTML: If our test only checks for the test ID, the test would pass while this is not a valid implementation of a button and will cause a severe accessibility issue: But if we write the assertion with , the test would fail, which enables us to ensure the validity of the DOM: https://testing- N/A Update the guide and recommend using and instead of . We can also add the link to the for other recommended locators. No response
I agree. Recently, I've opened two PRs with E2E tests, and although I followed the guide and used , it just doesn't feel right to do it this way.
can you assign to me
I've created to update the guide with the new recommendation. For Hacktoberfest PRs that have already been using test IDs, I think we should still respect the authors' efforts and accept their code addition, and we can always improve the tests later on.
Change:
); const ShowProjectAndGithubLinks = ( <del> <div className='solutions-dropdown'> </del> <ins> <div> </ins> <Dropdown id={`dropdown-for-${id}-${randomIdSuffix}`}> <Dropdown.Toggle className='btn-invert'> {viewText}{' '}

Discussion:
contains a single CSS rule: This rule is not needed as the underline of the is already turned off by the component library. Remove Remove the class from
This issue is open for contribution. Please make sure you read our as well as our , we prioritize contributors following the instructions in our guides. Join us in our or our if you need help contributing; our moderators will guide you through this. Sometimes we may get more than one pull request. We typically accept the most quality contribution followed by the one that is made first. Happy contributing.
Change:
"tests": [], "type": "basejump", "challengeType": 4, <del> "isRequired": true </del> <ins> "isRequired": true, "nameEs": "Microservicio de metadatos de archivos", "descriptionEs": [ "<strong>Objetivo:</strong> Arma una aplicación de Pila Completa en JavaScript que sea funcionalmente similar a esta: <a href='https://cryptic-ridge-9197.herokuapp.com/' target='_blank'>https://cryptic-ridge-9197.herokuapp.com/</a>  y despliegala en Heroku.", "Ten en cuenta que para cada proyecto, deberías crear un nuevo repositorio en GitHub y un nuevo proyecto en Heroku. Si no recuerdas como hacer esto, vuelve a visitar <a href='/challenges/get-set-for-our-back-end-development-projects'>http://freecodecamp.com//challenges/get-set-for-our-back-end-development-projects</a>.", "Aquí están las historias de usuario específicas que debes implementar para este proyecto:", "<strong>Historia de Usuario:</strong> Puedo enviar un objeto FormData que incluya una subida de un archivo.", "<strong>Historia de Usuario:</strong> Cuando envío algo, recibiré el tamao del archivo en bytes en la respuesta JSON.", "<strong>Pista:</strong> Puede servirte este paquete: <a href='https://www.npmjs.com/package/multer' target='_blank'>https://www.npmjs.com/package/multer</a>", "Una vez que hayas terminado de implementar estas historias de usuarios, pulsa el botón "I've completed this challenge" e introduce los URLs de tu repositorio en GitHub y de tu aplicación en vivo en Heroku.", "Puedes obtener retroalimentación sobre tu proyecto por parte de otros campistas, compartiendolo en nuestra <a href='//gitter.im/freecodecamp/codereview' target='_blank'>Sala de chat para revisión de código</a>. También puedes compartirlo en Twitter y en el campamento de tu ciudad (en Facebook)." ] </ins> } ] }

Discussion:
[x] Get Set for our Back End Development Projects [x] Timestamp Microservice [x] Request Header Parser Microservice [x] URL Shortener Microservice [x] Image Search Abstraction Layer [x] File Metadata Microservice
Currently working on this.
I just used part of the PR that you closed. Thank you. Blessings.
Change:
"tests": [], "type": "basejump", "challengeType": 4, <del> "isRequired": true </del> <ins> "isRequired": true, "nameEs": "Microservicio de Marca de Tiempo", "descriptionEs": [ "<strong>Objetivo:</strong> Arma una aplicación de Pila Completa en JavaScript que sea funcionalmente similar a esta: <a href='https://timestamp-ms.herokuapp.com/' target='_blank'>https://timestamp-ms.herokuapp.com/</a> y despliegala en Heroku.", "Ten en cuenta que para cada proyecto, deberías crear un nuevo repositorio en GitHub y un nuevo proyecto en Heroku. Si no recuerdas como hacer esto, vuelve a visitar <a href='/challenges/get-set-for-our-back-end-development-projects'>http://freecodecamp.com//challenges/get-set-for-our-back-end-development-projects</a>.", "Aquí están las historias de usuario específicas que debes implementar para este proyecto:", "<strong>Historia de Usuario:</strong> Puedo pasar una cadena como parámetro y comprobará si contiene o no una marca de tiempo para Unix o una fecha en lenguaje natural en inglés (Ejemplo: January 1, 2016).", "<strong>Historia de Usuario:</strong> Si tiene una marca de tiempo para Unix, devuelve tanto la marca de tiempo de Unix como la fecha en lenguaje natural.", "<strong>Historia de Usuario:</strong> Si no contiene una fecha ni una marca de tiempo para Unix, devolverá esas propiedades en <code>null</code>.", "Una vez que hayas terminado de implementar estas historias de usuarios, pulsa el botón "I've completed this challenge" e introduce los URLs de tu repositorio en GitHub y de tu aplicación en vivo en Heroku.", "Puedes obtener retroalimentación sobre tu proyecto por parte de otros campistas, compartiendolo en nuestra <a href='//gitter.im/freecodecamp/codereview' target='_blank'>Sala de chat para revisión de código</a>. También puedes compartirlo en Twitter y en el campamento de tu ciudad (en Facebook)." ] </ins> }, { "id": "bd7158d8c443edefaeb5bdff",

Discussion:
[x] Get Set for our Back End Development Projects [x] Timestamp Microservice [x] Request Header Parser Microservice [x] URL Shortener Microservice [x] Image Search Abstraction Layer [x] File Metadata Microservice
Currently working on this.
I just used part of the PR that you closed. Thank you. Blessings.
Change:
background-color: var(--gray-10) !important; } <ins> .nav-lang-menu li:first-child .nav-link:hover { color: var(--love-dark) !important; } </ins> .nav-lang-button { display: flex; justify-content: space-between;

Discussion:
The language selection menu is not intuitive about the no. of available options. It's a bit paradoxical at the moment: You will not notice additional options until you start scrolling while being on top of the options. You will not start scrolling until you know there are additional options. to '/learn' on 'Menu' down to 'Change Language' the cursor on the options Scrolling while being in the area of the listed options. menu should be very clean and intuitive. "Cancel Change" option should have some form of visual separation. https://user- Device: All Devices OS: All OS Browser: All Browsers Version: All Versions No response
this will start becoming evident with more languages on the list. The quickest and simplest way this can be handled is by slightly increasing the height of the list and decreasing the height of the hover-state highlight (each item). That will leave some space at the bottom of the last item, intuitively letting the user know there is more to be looked at. Currently, the perfect-sized (height) items and the overall height of the list make it difficult to notice more entries. Finally, that "Cancel" option should be a different color or have some form of visual separation.
is this issue still being worked on? If not, I would like to take it.
That makes sense, I thought we fixed that. should be removed for and
or anyone else interested, this is up for grabs.
This is what makes the language menu full length so no vertical scroll bar appears. Originally, I had the language menu set so that a vertical scroll bar would appear if it was taller than the main menu. But it was decided that there shouldn't be a vertical scroll bar, the language menu should be as tall as necessary so no scroll bar was needed. Is this what we still want? Even as we continue to add even more languages?
thanks for bringing this up. Ideally we would need to show as many languages as possible in a viewport and display a minified scroll bar if the list exceeds the height viewport minus of the navigation. We could show a scrollbar initially as you recommended, but the dropdown needs expand further than the main menu if needed.
Change:
return next(err); } req.flash('success', { msg: 'Success! You are logged in.' }); <ins> if (/hotStories/.test(req.session.returnTo)) { return res.redirect('../news'); } </ins> return res.redirect(req.session.returnTo || '/'); }); })(req, res, next);

Discussion:
Seeing this in production here: solution: Use and/or check for user existence and end early. cc:
Change:
.fcc_searchBar { flex-grow: 1; padding: 0 10px; <ins> max-height: 33px; </ins> } .fcc_searchBar .ais-SearchBox-input,

Discussion:
Describe the bug On retina displays, this is what Learn's search navbar looks like on retina displays (2012 and beyond Macbooks): <img width="1064" alt="welcometolearnfreecodecamp" src="https://user-"Note that the Guide's navbar looks fine on Retina displays: <img width="1222" alt="freecodecamp_guide" src="https://user-"To Reproduce Steps to reproduce the behavior: to '...' on '....' down to '....' error Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Desktop (please complete the following information): OS: [e.g. iOS] Browser [e.g. chrome, safari] Version [e.g. 22] Smartphone (please complete the following information): Device: [e.g. iPhone6] OS: [e.g. iOS8.1] Browser [e.g. stock browser, safari] Version [e.g. 22] Additional context Add any other context about the problem here.
sorry, I believe this is due to some of the changes I made way back in Fortunately, I don't think this was brought over into the monorepo. Does the navbar look like that when the site is running locally?
Yes - the navbar still looks slightly offset on my retina display when running locally: <img width="1187" alt="welcometolearnfreecodecamp" src="https://user-"The search field is way too wide, too, though that probably deserves a separate issue
sorry about that! Will take another crack at fixing the search bar soon.
Hi Thanks for working on this. Please let me know when you have the PR ready so we could review and merge it ASAP.
sorry for the delay with this! Been flying a bit blind since I don't have a Retina screen device of my own. Ended up using some kiosk MacBooks and playing with the CSS in the browser. Could only test with Safari, but I suspect that this is caused by the search bar having an undefined height. I'm just about to submit a PR, so could you and check it out when you can?
Change:
import React, { useContext } from 'react'; import { FormContext } from '../form-group/form-group'; <del> import { FormControlFeedback as Feedback } from './form-control-feedback'; import { FormControlStatic as Static } from './form-control-static'; </del> <ins> import { FormControlFeedback } from './form-control-feedback'; import { FormControlStatic } from './form-control-static'; </ins> import { FormControlProps } from './types'; // Uses controlId from <FormGroup> if not explicitly specified. // type Only relevant if componentClass is 'input'. <ins> let variantClass: string; const defaultClasses = 'outline-0 block w-full py-1.5 px-2.5 text-md text-foreground-primary ' + 'bg-background-primary bg-none rounded-none border-1 border-solid ' + 'border-background-quaternary shadow-none ' + 'transition ease-in-out duration-150 focus:border-foreground-tertiary'; </ins> const FormControl = ({ id,

Discussion:
onChange: func value?: string componentClass?: string placeholder?: string name?: string required?: string rows?: 4 type?: 'text' 'url'FormControl FormControl.Feedback
Form control for chapter: Need to alter the props to account for chapter needs, here is the link to the chakira component
Which prop is being used in the chapter that we are not passing in the component library? Since chapter views are limited, it might be easier to create the components with learn specifications and use those props to control the component. does that make senes?
Instead of checking the chaikra library and comparing it with the current component, I am better off checking chapter itself for prop it's using. for example, in this file we are using and , so I note these down and check if these 2 props are different from the props we are using. depend on how different they are, I may do from the follow: Add new value to existing prop. Add new prop to the component. Do nothing.
Here is what I propose we do. We could continue building the components with the learn spec and ship them. For the second sprint, we collect the Chapter requirements and update the components accordingly.
Change:
"title": "Learn Modern JavaScript Methods by Building Football Team Cards", "intro": [ "One common aspect of building web applications: processing datasets, and then outputting information to the screen. In this sports team cards project, you'll learn how to work with DOM manipulation, object destructuring, event handling, and data filtering.", <del> "This project will cover concepts like switch statements, default parameters, <code>Object.freeze()</code>, the <code>map()</code> method, and more." </del> <ins> "This project will cover concepts like, default parameters, <code>Object.freeze()</code>, and reinforce your knowledge of the <code>switch</code> statement and <code>map()</code> method." </ins> ] }, "learn-advanced-array-methods-by-building-a-statistics-calculator": {

Discussion:
The description of the project to build football team cards in the js beta curriculum says: In this project, you will build a set of football team cards and learn about nested objects, object destructuring, default parameters, event listeners, and switch statements. But switch statements were introduced in the date formatter project (step 16, 17). I think the description should be modified therefore to not mention learning switch statements. I haven't actually done this project, so I don't actually know if it re-teaches switch statements or not. (it would be nice if the date formatter description mentioned learning about switch statements though) N/A N/A No response N/A No response
I don't really get the title of this challenge, what "modern javascript methods" is it referring to, is it just the ? Because surely both map and filter has already been taught at this point. I'm also not sure the switch is really needed. It seems a little verbose and a lot of boilerplate. Compared to say:
Let's go ahead and remove switch statements from the description and the first step.
I feel like the switch used in the code is because the idea of the challenge, among other things, was to teach it. It takes up a lot of the total code. Not mentioning it, doesn't really change that fact. Not unless, we remove the switch from the code as well.
That's a fair point. I'd be fine rewriting the challenge to use the example you shared earlier.
Hi! I am a new, first time contributor. Can I put up a PR for this issue? Seems like a simple fix, just removing 'switch statements' from description and first step
It could be seen as reinforcement. I'm not saying we have to remove it, I'm just saying it seems like part of the point of this challenge was to teach the switch, which is why it is in the description and the code. Not sure how often we use switch statements, but this project is definitely reinforcing it. So we might want to keep it just for that reason. This also isn't the first time we teach and it is in the description as well. Maybe that could be it, reinforcement. Or something like that?
changing the description slightly seems like an easy way to fix the issue
I like this copy, yeah.
Change:
"nav": { "forum": "https://forum.freecodecamp.org/", "news": "https://freecodecamp.org/news/" <ins> }, "help": { "HTML-CSS": "HTML-CSS", "JavaScript": "JavaScript", "Python": "Python", "Relational Databases": "Relational Databases" </ins> } }

Discussion:
As we are now rolling out the curriculum in Chinese and Spanish, we need to think about how to get the button to work for the two languages. Currently, when the button is clicked, the user is taken to the English forum () where a pre-populated topic message (in English) is displayed for the user to fill in with relevant information. These topics are dynamically generated before the post is created on the forum, so we will just need to make use of the file for the content of the topics. Also, we will need to route to the correct forum url for Chinese and target the correct subforum for Spanish.
So the Chinese links work correctly, because the Chinese forum is hosted at a different domain (which is passed in to the environment variable). For Espanol, as it currently stands the category comes from the value returned by the .
Change:
}; } <del> updateData.$push = { ...updateData.$push, completedChallenges: finalChallenge </del> <ins> updateData.$set = { completedChallenges: _.uniqBy( [finalChallenge, ...completedChallenges], 'id' ) </ins> }; if (

Discussion:
Completing projects from the settings page, submitting a url, dose not increment the points a user has. We need to push a new timestamp to the users array.
Hi I can help out with this. Am I correct in thinking that this should be done in the file? If so, I'll look at for some guidance.
Change:
assert(telephoneCheck('(555)5(55?)-5555') === false); ``` <ins> `telephoneCheck("55 55-55-555-5")` should return `false`. ```js assert(telephoneCheck('55 55-55-555-5') === false); ``` </ins> # --seed-- ## --seed-contents--

Discussion:
<!-- NOTE: If you're reporting a security issue, don't create a GitHub issue. Instead, email We will look into it immediately. --There is a problem with the test for the telephone validator. They pass validators which do not check for proper spacing or dashing. (i. e. my validator will return true for 55 55-55-555-5). This is the my code which passed the test, but really shouldn't have: I'd recommend adding some extra tests to the exercise. Here is a link to the Tell us about your browser and operating system: Browser Name: Chrome Browser Version: Version 87.0.4280.88 Operating System: Windows 10 If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box):
Link to Link to
I guess a simple fix would be to add this test. should be false