The big refactor

.gitignore

@@ -1,11 +1,15 @@
 /*.js
+!index.js
+/src/*.js
 /*.d.ts
 /*.log
 *.js.map
 bundle.js
 npm-debug.log
-.test/
+/.test/
+/.vscode/
 /test/execution-tests/**/typings
 !/test/**/expectedOutput-*/**
 /node_modules
-!build.js
+/dist
+!build.js

.npmignore

@@ -1,4 +1,5 @@
 *.ts
+.vscode
+.test
 test
-.*
-typings
+src

.travis.yml

@@ -1,9 +1,13 @@
 language: node_js
 node_js:
+  - "4.0"
+  - "5.0"
   - "6.0"
 sudo: false
 install:
+  - npm install npm -g
   - npm install
+  - npm run build
   - npm install $TYPESCRIPT
 env:
   - TYPESCRIPT=typescript@1.6.2

CHANGELOG.md

@@ -1,7 +1,8 @@
 # Changelog
 
-## v0.9.x - NOT RELEASED YET
+## v1.0.0
 
+- [General refactor of ts-loader; some performance improvements](https://github.com/TypeStrong/ts-loader/pull/343) [#335] - thanks @johnnyreilly
 - [Make the loader resilient to watched declaration files being removed.](https://github.com/TypeStrong/ts-loader/pull/281) - thanks @opichals
 
 ## v0.9.5
@@ -15,22 +16,22 @@
 
 ## v0.9.3
 
-- [Added support for allowJs](https://github.com/TypeStrong/ts-loader/pull/320) (#316)
+- [Added support for allowJs](https://github.com/TypeStrong/ts-loader/pull/320) (#316) - thanks @dschnare
 
 ## v0.9.2
 
-- [Added support for @types](https://github.com/TypeStrong/ts-loader/pull/318) (#247)
+- [Added support for @types](https://github.com/TypeStrong/ts-loader/pull/318) (#247) -thanks @basarat for the ideas
 
 ## v0.9.1
 
-- [Normalize dependency graph paths - Fix broken dependencies on Windows ](https://github.com/TypeStrong/ts-loader/pull/286)
-- [Fixed the declaration issue](https://github.com/TypeStrong/ts-loader/pull/307) (#214 part deux)
+- [Normalize dependency graph paths - Fix broken dependencies on Windows ](https://github.com/TypeStrong/ts-loader/pull/286) - thanks @pzavolinsky
+- [Fixed the declaration issue](https://github.com/TypeStrong/ts-loader/pull/307) (#214 part deux) - thanks @dizel3d
 
 ## v0.9.0
 
-- [Made ts-loader compatible with node v6](https://github.com/TypeStrong/ts-loader/commit/a4f835345e495f45b40365f025afce72d1817996)
-- [Fixed the declaration issue](https://github.com/TypeStrong/ts-loader/commit/3bb0fec73a2fab47953b51d256f0f5378f236ad1) (#214)
-- [Declarations update independent of compiler.watchFileSystem](https://github.com/TypeStrong/ts-loader/pull/167/commits/ae824b2676b226bdd0c860a787754a4ae28e339c) (#155)
+- [Made ts-loader compatible with node v6](https://github.com/TypeStrong/ts-loader/commit/a4f835345e495f45b40365f025afce72d1817996) - thanks @Blechhirn
+- [Fixed the declaration issue](https://github.com/TypeStrong/ts-loader/commit/3bb0fec73a2fab47953b51d256f0f5378f236ad1) (#214) - thanks @17cupsofcoffee
+- [Declarations update independent of compiler.watchFileSystem](https://github.com/TypeStrong/ts-loader/pull/167/commits/ae824b2676b226bdd0c860a787754a4ae28e339c) (#155) - thanks @opichals
 
 Now built using TypeScript v2.0
 

CONTRIBUTING.md

@@ -19,7 +19,7 @@ npm run build
 ## Changing
 
 Most of the information you need to contribute code changes can [be found here](https://guides.github.com/activities/contributing-to-open-source/).
-In short: fork, branch, make your changes, and submit a pull request.
+In short: fork, make your changes, and submit a pull request.
 
 ## Testing
 
@@ -32,138 +32,31 @@ To run execution tests alone use `npm run execution-tests`.
 
 Not all bugs/features necessarily fit into either framework and that's OK. However, most do and therefore you should make every effort to create at least one test which demonstrates the issue or exercises the feature. Use your judgement to decide whether you think a comparison test or an execution test is most appropriate.
 
-### Comparison Test Pack
-
-This test pack comprises a number of mini-typescript projects which, as part of the test run, are each run through webpack.  
-The outputs (both compiled JavaScript and webpack compilation output) are compared against a set of expected 
-outputs. These are particularly useful for testing failure cases; that is testing scenarios where you expect compilation
-to fail and ensuring the failure is what you expect. For example, ensuring the presence of error messages from the TypeScript 
-compiler in the output etc.
-
-The comparison test pack can be found under `/test/comparison-tests`. The test harness uses certain conventions. All tests have their own directory under `/test/comparison-tests`, eg `/test/comparison-tests/someFeature`. Each test should have a `webpack.config.js` file which follows this general convention:
-
-```javascript
-module.exports = {
-    entry: './app.ts',
-    output: {
-        filename: 'bundle.js'
-    },
-    resolve: {
-        extensions: ['', '.ts', 'tsx', '.js']
-    },
-    module: {
-        loaders: [
-            { test: /\.tsx?$/, loader: 'ts-loader' }
-        ]
-    }
-}
-
-// for test harness purposes only, you would not need this in a normal project
-module.exports.resolveLoader = { alias: { 'ts-loader': require('path').join(__dirname, "../../index.js") } }
-```
-
-You can run all the tests in the Comparison Test Pack with `npm run comparison-tests`. You can also go into an individual test directory and manually build a project using `webpack` or `webpack --watch`. This can be useful both when developing the test and also when fixing an issue or adding a feature.
-
-Each test should have an `expectedOutput` directory which contains any webpack filesystem output (typically `bundle.js` and possibly `bundle.js.map`) and any console output. stdout should go in `output.txt` and stderr should go in `err.txt`.
-
-To run all the tests use:
-
-`npm run comparison-tests`.
-
-If you would like to run just a single test then:
-
-`npm run comparison-tests -- --single-test nameOfTest`
-
-#### Regenerating test data
-
-As a convenience it is possible to regenerate the expected output from the actual output. This is useful when creating new tests and also when making a change that affects multiple existing tests. To run use:
-
-`npm run comparison-tests -- --save-output`. 
-
-Note that all tests will automatically pass when using this feature. You should double check the generated files to make sure
-the output is indeed correct.
-
-If you would like to regenerate a single test then combine `--save-output` with 
-`--single-test` like so:
-
-`npm run comparison-tests -- --save-output --single-test nameOfTest`
-
-#### Watch Specific Tests
-
-The test harness additionally supports tests which exercise watch mode, since that is such an integral part of webpack. Watch mode tests are just the as standard comparison tests.  However, after the initial compilation and comparison, a series of "patches" are applied and tested. 
-
-The patches live in folders following the naming convention of `/patchN` starting with 0. After the initial compilation and comparison, the patches are iterated through and the files in place are replaced with any modified files in the `/patchN` directory.  After each patch application the compilation / comparison is performed once more.
-
-For example:
-
-Initial state:
-- test/someFeature/app.ts
-- test/someFeature/expectedOutput/bundle.js
-- test/someFeature/expectedOutput/output.txt
-
-patch0 is applied:
-- test/someFeature/patch0/app.ts - *modified file*
-- test/someFeature/expectedOutput/patch0/bundle.js - *bundle after applying patch*
-- test/someFeature/expectedOutput/patch0/output.txt - *output after applying patch*
-
-### Execution Test Pack
-
-This test pack is made up of a number of mini-typescript projects which include a test suite.  As part of the test run, each project is compiled and the test suite run using Karma. So this test pack is different from the comparison test pack in that it **executes the compiled code**. This test pack is useful for testing expected behaviour.  (It's also reassuring to see your
-code being executed.)
-
-These tests are executed more widely that the comparison tests; we aim to run these against each version of TypeScript defined in our CI build matrices. (Take a look at [`appveyor.yml`](appveyor.yml) and [`.travis.yml`](.travis.yml) for details.)
-
-#### Structure
-
-The execution test pack can be found under `/test/execution-tests`. Like the comparison test pack, the execution test pack uses certain conventions. All tests have their own directory under `/test/execution-tests`, eg `/test/execution-tests/someFeature`. Each test is expected to have a `karma.conf.js` file and a `webpack.config.js` file.
-
-If a test requires a minimum version of TypeScript then the test directory should be prefixed with the minimum TypeScript version.  For example, the `2.0.3_es2016` test requires a minimum TypeScript version of 2.0.3; if the installed version is lower than the test needs then the test will be skipped.
-
-**IMPORTANT**
-
-In order that the local version of ts-loader is resolved for tests a `webpack.config.js` file will need to include this line:
-
-```
-// for test harness purposes only, you would not need this in a normal project
-module.exports.resolveLoader = { alias: { 'ts-loader': path.join(__dirname, "../../../index.js") } }
-// note that there are 3 ../ here as compared with only 2 for the comparison tests
-```
-
-And likewise the `karma.conf.js` will need to reuse this like so:
-
-```
-    webpack: {
-      devtool: 'inline-source-map',
-      debug: true,
-      module: {
-          loaders: webpackConfig.module.loaders
-      },
-      resolve: webpackConfig.resolve,
-
-      // for test harness purposes only, you would not need this in a normal project
-      resolveLoader: webpackConfig.resolveLoader
-    },
-```
-
-Without this, the test won't be able to resolve ts-loader and webpack won't find your TypeScript tests.
-
-#### What sort of tests can be included?
-
-It's pretty much your choice what goes in testwise.  At present there are only Jasmine tests in place; it should be possible to put any test in place that Karma is compatible with. The test pack also expects a `typings.json` file and calls `typings install` in each. **Be warned, type definitions are not installed until the test framework has been run.**  So if you're wanting to refactor a test you'll need to `typings install` if the requisite typings have not yet been installed. It's possible / probably that this may changed in the future; 
-particularly to cater for situations where types should be acquired via npm etc.
+To read about the comparison test pack take a look [here](test/comparison-tests/README.md)
+To read about the execution test pack take a look [here](test/execution-tests/README.md)
 
-#### Running / debugging the tests
+## Publishing
 
-To run all the tests use:
+So the time has come to publish the latest version of ts-loader to npm. Exciting!
 
-`npm run execution-tests`.
+Before you can actually publish make sure the following statements are true:
 
-If you would like to run just a single test then:
+- Tests should be green
+- The version number in [package.json](package.json) has been incremented.
+- The [changelog](CHANGELOG.md) has been updated with details of the changes in this release.  Where possible include the details of the issues affected and the PRs raised.
 
-`npm run execution-tests -- --single-test nameOfTest`
+OK - you're actually ready.  We're going to publish.  Here we need tread carefully. Follow these steps: 
 
-It's pretty handy to be able to debug tests; for that reason you can run a single test in watch mode like this:
+- clone ts-loader from the main repo with this command: `https://github.com/TypeStrong/ts-loader.git`
+- [Login to npm](https://docs.npmjs.com/cli/adduser) if you need to: `npm login`
+- install ts-loaders packages with `npm install`
+- build ts-loader with `npm run build`
+- run the tests to ensure all is still good: `npm test`
 
-`npm run execution-tests -- --single-test nameOfTest --watch`
+If all the test passed then we're going to ship:
+- tag the release in git.  You can see existing tags with the command `git tag`.  If the version in your `package.json` is `"1.0.1"` then you would tag the release like so: `git tag v1.0.1`.  For more on type of tags we're using read [here](https://git-scm.com/book/en/v2/Git-Basics-Tagging#Lightweight-Tags).
+- Push the tag so the new version will show up in the [releases](https://github.com/TypeStrong/ts-loader/releases): `git push origin --tags`
+- On the releases page, click the "Draft a new release button" and, on the presented page, select the version you've just released, name it and copy in the new markdown that you added to the [changelog](CHANGELOG.md).
+- Now the big moment: `npm publish`
 
-Then you can fire up http://localhost:9876/ and the world's your oyster.
+You've released!  Pat yourself on the back.

README.md

@@ -200,7 +200,7 @@ require('!style!css!./style.css');
 
 The same basic process is required for code splitting. In this case, you `import` modules you need but you
 don't directly use them. Instead you require them at [split points](http://webpack.github.io/docs/code-splitting.html#defining-a-split-point).
-See [this example](test/codeSplitting) for more details.
+See [this example](test/comparison-tests/codeSplitting) and [this example](test/comparison-tests/es6codeSplitting) for more details.
 
 ## License
 

UPGRADE.md

@@ -1,5 +1,12 @@
 # Upgrade Guide
 
+## v0.9.x to 1.0.x
+
+We no longer support Node 0.12 officially since it is being end-of-lifed.  
+That said, ts-loader will probably still work with it at present. 
+(Though you shouldn't depend on it and ought to upgrade your version of node).
+Otherwise there are no breaking changes known of; if you find any then let us know!
+
 ## v0.8.x to 0.9.x
 
 No breaking changes known of; if there are then let us know!

appveyor.yml

@@ -9,10 +9,10 @@ environment:
 install:
   - ps: Install-Product node $env:nodejs_version
   - npm install
+  - npm run build
   - npm install %TYPESCRIPT%
 test_script:
   - node --version
   - npm --version
-  - npm run build
   - npm test
 build: off

index.js

@@ -0,0 +1,3 @@
+var loader = require('./dist');
+
+module.exports = loader;