freeCodeCamp
Synchronizing learn with curriculum during development
Is your feature request related to a problem? Please describe. On my computer, compiling learn takes several minutes (usually 5-10) and waiting this long to view a change with curriculum is just impractical when making minor adjustments.
Describe the solution you'd like
I'd like to be able to run something similar to unpacked, but there is an editor, and the learning tests (i.e buffer should be 64 bytes) can be run. It should not affect learn progress. This can be done by, when unpacking (maybe a different kind of unpack?), parsing the tests section of the challenge, and converting it to the TAP test syntax. (I have no idea how that would be repacked, however. Probably some very structured comments, like the whole<!--description--> stuff.)
Describe alternatives you've considered Testing it normally with learn, and using the unpacked version, but using the test suite to test pre-written code.
Additional context My computer is rather old, so this is really just a convenience thing. Maybe I'm the only one who's developing with such a slow computer, and for everyone else, running learn takes a few seconds.
Many thanks.
Hi @Flarp! I have a question for you.
compiling learn takes several minutes (usually 5-10) and waiting this long to view a change with curriculum
If you make a change in curriculum repo then how do you get it to reflect in the learn repo? I currently change the files in node_modules to test the changes made in curriculum files.
Whoops, my bad.
@anku255
Modify the package.json file, replacing the version number of @freecodecamp/curriculum with file:/path/to/local/curriculum, an installation of the curriculum repo from Git.
@Flarp, cool! That's way easier than modifying node_modules every time to test changes. Thanks!
Glad to be helpful, but does anyone have a work around for this right now, where I can run each item in curriculum independent of learn?
Hey @Flarp while this probably isn't exactly what you're after, hopefully it helps.
You can avoid rebuilding learn by editing the Gatsby cache directly.
First off get learn running via yarn develop. That should populate learn's .cache/json directory with the challenge data. Once you've found the file you want, you can just copy over any changes you want from curriculum and they'll appear when you reload that page.
@ojeytonwilliams That should do it, I'll test that out soon (either tonight or tomorrow) and fill you in on how it goes, thank you!
Actually, this doesn't solve everything, the changes in learn are not reflected in curriculum, and vice versa. Also, you need to recompile if you make a new page.
@Flarp Indeed, it's far from a perfect solution. What I think would be ideal is if a change in curriculum was immediately reflected in learn. Gatsby should do this, but at the moment it's ignoring changes in curriculum.
I've been looking into this, and I'll keep you posted, but I haven't made great strides yet.
@ojeytonwilliams My approach would be to use require.resolve() to locate the module directory (as said above, I don't use the default node_modules dir, as it's counter-intuitive for development), and then using some form of observable on the directory with Gatsby
@Flarp I think yarn link should do the first part of the job - as you say, you want to use a local version of curriculum.
The tricky bit is setting up the observable, but I think I'm getting there. I'm also learning a bit about Gatsby in the process.
https://github.com/freeCodeCamp/learn/blob/30b5516f826e98ad23daee51f2e4ed89d54c05b6/plugins/fcc-source-challenges/gatsby-node.js#L47
This line seems to already do what we want, it's simply commented out. I'll uncomment and get back to you on anything that occurs.
Upon uncommenting (and a lot of other minor changes throughout both learn and curriculum), I guess it was commented out due to it causing Gatsby to recompile infinitely. However, it does not update like it should.
Indeed. The challenge plugin's a bit odd - it's based on the gatsby-source-filesystem plugin and has a few bits of redundant code and some quirks. I've managed to get something working partially, but it's not pull request ready.
Nonetheless, I'll clean up what I have tomorrow and push it to my fork, so you can take a look.
https://github.com/Flarp/curriculum/commit/e7315f651658911797facf74033e77fdc1c8e79f
https://github.com/Flarp/learn/commit/a8775a70398b95779bd14820188df80f10ec4256
It looks like we were going in similar directions. learn and curriculum
The key problems I encountered were that the json was being read with require, and getting cached. Also if you want to do your work in the challenges directory (rather than dist/challenges), as is reasonable, you can't just pipe any changes over to dist. If you do, then occasionally learn will read an incomplete json file and crash.
There's also weird issue with watches - Gatsby keeps trying to add them, and I've not figured out why. This doesn't break anything that I'm aware of, but it's troubling.
Finally I thought it was a nice touch using require.resolve to get the curriculum directory - much better than what I was doing!
A mind boggling error that came about during development was Vim creating copies of files (for saving purposes) faster than Node could read them, which caused learn to crash. I fixed this by adding the tilde (~) as a character ignored by the watcher.
You can read more about this oddity here
(This isn't reflected in my codebase because I was directly editing /dist)
I also disagree with removing the ignored options in the watcher, those files should not be reported to Gatsby when modified.
Most of what we're doing actually pertains to the learn repository, so this issue will be continued in the issue above.
Should have thought of that. I figured that nothing needed ignoring, since it was just looking at dist. Oh well, lesson learned!
On Fri, 20 Jul 2018, 18:38 Flarp, [email protected] wrote:
A mind boggling error that came about during development was Vim creating copies of files (for saving purposes) faster than Node could read them, which caused learn to crash. I fixed this by adding the tilde (~) as a character ignored by the watcher.
You can read more about this oddity (here)[ https://askubuntu.com/questions/173151/what-does-the-tilde-at-the-end-of-a-file-name-stand-for ]
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freeCodeCamp/curriculum/issues/68#issuecomment-406656316, or mute the thread https://github.com/notifications/unsubscribe-auth/APEdzvVHglVrGS_dNSeW-9mRTYfIHjr6ks5uIgd9gaJpZM4U598V .
@Flarp So, I looked into this a bit more and it's a bit odd. Are you developing on a Mac, by any chance? For some reason, it seems that chokidar ignores vim's tmp files on Linux, but not on Mac. I'll make sure they're ignored regardless.
As for the rest of the files, I agree they shouldn't be reported to Gatsby, but they also shouldn't be appearing in the dist directory in the first place!
It is. Regardless, I think I've fixed the problem - by just watching .json files.
Would you mind re-opening this? The changes span both learn and curriculum after all.