👍

@ghost and @jbrantly can you take a look.

Hey, this looks good. I did some tests with loading in browser as a script, bundling with webpack and bundling with browserify. The good news is the change to check process makes all three take the correct codepath. However, there is one more additional change you could possibly make.

Browserify by default shims the fs module. This means that prior to this PR, browserify would actually bundle fine. The downside is that the getNodeSystem path was still taken at runtime with shimmed modules which could have I-don't-know-what kind of effect. After this PR, the correct path is taken.

webpack does not shim the fs module by default. This means that if you simply require('typescript') without any extra configuration webpack will error that it can't find the fs module. In order to get around this I had to add extra configuration to tell webpack not to scan typescript for imports. However, it's pretty simple to fix so that webpack also bundles without configuration. Both webpack and browserify support the "browser" field in package.json. If you were to also modify package.json to add the following...

"browser": {
  "buffer": false,
  "fs": false,
  "os": false,
  "path": false
}

... this would essentially say "If any bundlers try to include this for the browser, ignore any attempts to import the 'fs', 'os' and 'path' modules". I tested this and it worked beautifully. It causes webpack and browserify to have the same default behavior, which is that the various calls to import fs, path and os are shimmed to be empty (which is fine since they're not used at runtime).

buffer is included because both bundlers also include an implementation of Buffer (which is referenced once in getNodeSystem). That takes care of browserify but not webpack, which I think is fine. You can only do so much, and it doesn't hurt anything other than filesize.

@jbrantly is there a different check that would succeeded with browserify but fail for webpack that we should be using instead?

@mhegazy Not sure I understand. The typeof process !== "undefined" && process.nextTick && !process.browser check works as intended. The other stuff is just about bundling which isn't affected by the check.

@mhegazy there are actually two places where typescript behave incorrectly when it was used with webpack.

• during bundling webpack tries to statically discover all imported packages. At this point it finds: fs, os and path modules. Webpack does not provide shim for fs so it results in error during bundling. "browser" section in 'package.json' will suppress attempts to discover these modules so this category of errors will go away.
• in runtime when bundle is loaded it will use wrong code path (because of weak check for node-like environments) and try to use node-based sys in browser - this issue is already fixed in this PR by using proper check

This looks good from my perspective. Even though I don't use TypeScript like this I am a big fan of webpack so I think it's really cool that you guys support this scenario. Thanks!