We Keep Coding

Routes being cached by service worker in react

We are in the process of building a new website for the company I work for which is written in React using CRA. Browser push notifications and a PWA are both required so a service worker is essential, however I beleive the service worker is responsible for some fairly major caching issues.
The website is not yet in production however I added a new page yesterday (and this has happened a few times before) and once deployed to our dev environment nobody in the office was able to access it - they were simply redirected to the homepage (as if the route didn't exist) until they cleared their cache then the route loaded with no issues.
I've read a little bit on semantic versioning however the articles all seem to use NPM rather than yarn and are versioned locally (which isn't great with a team of 8 working on this project) using npm version patch etc.
We are using MS Azure as the build and release pipeline which I assume would be the best place to set versions if this is required.
My question is what are the steps to aviod this problem and am I on the correct lines thinking versioning will mitigate?

Semantic versioning in this context doesn't make any sense, you've been reading most likely about packages (libraries, frameworks) that are published into NPM for the world to use. In CRA projects, and most other web projects too, versioning of your app happens by the build tools as they name the files based on their contents. The filenames include the hash of the contents and are versioned automatically when contents change, eg. app.iue9234980s.js becomes app.92384oujiuoisdf.js etc.
--
If you're using the default Service Worker setup provided by CRA, then you should look at src/serviceWorker.js. In the comments of that file it says
// This lets the app load faster on subsequent visits in production, and gives
// it offline capabilities. However, it also means that developers (and users)
// will only see deployed updates on subsequent visits to a page, after all the
// existing tabs open on the page have been closed, since previously cached
// resources are updated in the background.
What happens here is that the SW and the build process use Workbox SW library that is configured to use precache policy. In this policy, users get the last version that was previously cached from the browser's cache even if there's a new version available, then in the background SW updates the caches, and on another visit users get the newer version. This of course means that users might always be one version "late".
If this behaviour is not what you want, then you need to change src/serviceWorker.js and probably some configuration somewhere in CRA files. You should google something like "custom service workers with cra" for examples.
To better grasp what is happening – and especially what is correct and intended behaviour in differently configured cases – I really recommend (everyone) to read Google's primer on SWs themselves, here: https://developers.google.com/web/fundamentals/primers/service-workers
With understanding of the SWs basic principles, it is then probably useful to checkout the Workbox library https://developers.google.com/web/tools/workbox to see what it can offer for your app.
Reading and understanding the different aspects of SW is key here – it is excruciatinly easy to shoot yourself in the foot with SWs :)

Should Node.js only be used for "apps"?

Should Node.js be the basis of a website or be used only when certain functionality (eg. a chat room) is needed?
For example, in certain project, I'm using npm and have a node_modules folder and a package.json file in the main directory where all my code is.
However, the question I'm asking is whether or not this is good practice? Should Node.js only be used in, for example a chat-room/ folder? Or is it OK to use the same Node.js installation across an entire website, using when needed?

Many companies recently are having a hard job to detach their front end code from their server, hence, if you are starting a project from scratch, this is something you want to avoid.
Having low coupling applications will give you the flexibility to change your whole Front End stack without changing a single code in your API. Moreover, you will be able to use your API from different applications. They will now work independently.
The routing is how you define the URL, verb and opt parameters.
I hope that is what you have been struggling with.

Can I build my meteor app to work with several different sets of packages using different mobile exports?

I am working on a fairly large webapp in Meteor. As advised my many experts, a good way to go for large apps is to split the different parts of the code in separate packages, like, e.g. Telescope. I designed everything with this objective in mind so I expect to be able to port everything to a package based "architecture".
Moreover, I plan to open source soon, so it should be also easier to maintain that way.
I have different types of users. Depending on it, I would like to build the app differently:
One type of user is using the browser based version of the app. This user will get everything since I don't know how to selectively send some parts of the UI/client code (and I assume I can not)
One type of mobile user will only have a subset of packages.
Another type of mobile user will have another subset of packages.
So I have a browser full version (delivered by server) and two mobile app versions.
My understanding of mobile app exports is that I can compile different versions of my client code by removing/adding some specific packages before compiling, since a mobile app from meteor is a packaged version of all client side related code in an app.
Is that correct? Am I overlooking something?

I have been looking into this for a couple of days and things are changing in the Meteor world with the upcoming v1.3.
Regarding my question, yes, it could have been a way to go after meteor v1 if I believe this article
However, one of Meteor dev "announced" that Meteor will eventually drop the package system in favour of npm. One of the good things is that npm allows lazy (i.e. conditionnal & role based) loading of the different npm assets.
I will then look into this possibility. The one thing I miss would be an article or a tutorial showing what are the best practices when splitting a meteor app into npm packages. I assume that some, if not most of the advises for package based architecture are still standing.

JS Compiler / Package Manager for use with version control

I'm trying to grasp a bit of an idea here. And hoping someone can help clarify the best practice.
How do teams or pairs approach using a build system for javascript like grunt.js ?
I really want to break our large javascript files into smaller pieces and converting to AMD/Require isn't an option right now.
It seems the easiest way is to concatenate and minify to a master file. And we are using version control (SVN).
So I'm wondering what the best practice is here?
Are we asking for constant conflicts with the production file? How do other teams approach this?
Hope i made my question clear enough.
thanks in advance...

We recently faced a similar dilemma at my organization. Using AMD or RequireJS wasn't an option due the the sheer amount of legacy JavaScript code we have.
We ultimately went with grunt and came up with a "build" task that concatenates and minifies. Then, there's a completely separate "deploy" task that gzip's the files and uploads to Amazon S3.
We don't check in our concatenated/minified code to source control. In general, it's a good operational practice to have separate build and deploy tasks for your source code. For larger development teams, the deploy/build process would traditionally be done in a CI tool that runs whenever someone commits to SVN/git.
In your case, a simpler arrangement would be if you just manually deployed code from your development machine instead of have it automated from a CI tool. The problem with this setup is it's easy to run into conflicts with other team members.
That said, there is a growing number of open-source (Jenkins) or cloud-hosted (CircleCI) tools that might be worthwhile for you to look into.

Do not commit the output. Use a ci tool like teamcity to build and deploy. Only commit source files to source control.

Javascript Git client

Is there a Javascript implementation of Git?
I'm wanting to use HTML5 to create a rich Javascript application and have the idea that I could use git to track changes to the data. So, I'm wondering if there is a javascript implementation of a git client, or maybe some way of controlling a git repository by making POST requests.

Check out: https://github.com/danlucraft/git.js
A pure js implementation of git in javascript.

This https://github.com/creationix/js-git is and will be the future!
It is backed by a kickstarter campaign and has a very sound software design.
Many of the client use-cases such as git clone have been implemented
According the answer to my question on the issue tracker [1]. The author also plans to implement parts of the server side stuff to allow you to build a server with it.
https://github.com/creationix/js-git/issues/33

You can use https://github.com/isomorphic-git/isomorphic-git
isomorphic-git is a pure JavaScript reimplementation of git that works in both Node.js and browser JavaScript environments. It can read and write to git repositories, fetch from and push to git remotes (such as GitHub), all without any native C++ module
isomorphic-git is a continuation of https://github.com/creationix/js-git
isomorphic-git would not have been possible without the pioneering work by
#creationix and #chrisdickinson. Git is a tricky binary mess, and without
their examples (and their modules!) I would not have been able to come even
close to finishing this. They are geniuses ahead of their time.
Related questions:
Run git push from javascript hosted in static site
How to implement Git in pure Javascript to create a GUI?

I guess it depends on what you need, but there's a few related projects out there.
The most "robust" implementation I can think of is this one by the 280North crew (of Cappuccino fame).
There's also some server-side JavaScript projects underway (e.g., http://github.com/ajaxorg/node-github), but that won't run entirely within a browser client.
Update (for anyone else who comes across this):
Please be sure to check out vanthome's answer. Tim Caswell's js-git project is well funded and undoubtedly the best answer here at this time.

I just recently wrote a Git client called Nougit. Maybe this resembles something you are looking for?
$ npm install nougit
https://github.com/gordonwritescode/nougit
This is a full GUI, but the module inside named "git.js" is an API I wrote specifically to do what you are describing. Yank out the file, and you can use express to handle the http routes.