pinging @jbrantly as this change partially rolls back #4308

👍

I think that undoing #4308 is likely the wrong way to do it. That corrected behavior where browserify was "covering up" the issue (by shimming fs). I can see two ways of going about it.

1. Keep the current return undefined behavior for ts.sys in the case of a browser but reduce the test harness's dependency on it. For instance, the current error is because the CScript and Node executing environments currently always run and look like this:

   export let readFile: typeof IO.readFile = ts.sys.readFile;
   export let writeFile: typeof IO.writeFile = ts.sys.writeFile;

   but if you added some protection:

   let sys = ts.sys || {};
   export let readFile: typeof IO.readFile = sys.readFile;
   export let writeFile: typeof IO.writeFile = sys.writeFile;

   similar to the way you do the same for fso for CScript then that issue goes away. However, there are numerous other dependencies on ts.sys like useCaseSensitiveFileNames and newLine and it would probably be a pretty large undertaking to fix all occurrences. It's not clear to me if TypeScript, in general, is designed to run with ts.sys undefined.

2. Instead of returning undefined, go ahead and shim ts.sys in a minimal way that works for the browser. I did something like this:

   return {
       args: [],
       newLine: "\n",
       useCaseSensitiveFileNames: false,
       write: null,
       readFile: null,
       writeFile: null,
       resolvePath: null,
       fileExists: null,
       directoryExists: null,
       createDirectory: null,
       getExecutingFilePath: null,
       getCurrentDirectory: () => "/",
       readDirectory: null,
       exit: null
   };

   and that seemed to allow me to run the fourslash tests. This is roughly equivalent to allowing browserify to shim stuff.

closing in favor of #4394