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 Great! Thanks for the tip.

@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!

@Flarp you're very welcome! Definitely let me know how it goes.

@ojeytonwilliams It works wonders! Thank you so much!

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.

I'll push my fork too, show you the changes I've made

Flarp/curriculum@e7315f6

Flarp/learn@a8775a7

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.

@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!

I am on Arch Linux, so that's strange.

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.