pax_global_header 0000666 0000000 0000000 00000000064 14341700417 0014513 g ustar 00root root 0000000 0000000 52 comment=5e7220b65bd4e2709a76c9386cb939cdfed32eca
ts-loader-9.4.2/ 0000775 0000000 0000000 00000000000 14341700417 0013421 5 ustar 00root root 0000000 0000000 ts-loader-9.4.2/.devcontainer/ 0000775 0000000 0000000 00000000000 14341700417 0016160 5 ustar 00root root 0000000 0000000 ts-loader-9.4.2/.devcontainer/Dockerfile 0000664 0000000 0000000 00000003620 14341700417 0020153 0 ustar 00root root 0000000 0000000 #-------------------------------------------------------------------------------------------------------------
# Based on:
# https://github.com/microsoft/vscode-dev-containers/tree/v0.122.1/containers/typescript-node-14/.devcontainer/Dockerfile
#-------------------------------------------------------------------------------------------------------------
FROM mcr.microsoft.com/vscode/devcontainers/javascript-node:16
# The javascript-node image includes a non-root node user with sudo access. Use
# the "remoteUser" property in devcontainer.json to use it. On Linux, the container
# user's GID/UIDs will be updated to match your local UID/GID when using the image
# or dockerFile property. Update USER_UID/USER_GID below if you are using the
# dockerComposeFile property or want the image itself to start with different ID
# values. See https://aka.ms/vscode-remote/containers/non-root-user for details.
ARG USERNAME=node
ARG USER_UID=1000
ARG USER_GID=$USER_UID
# Alter node user as needed. eslint is installed by javascript image
RUN if [ "$USER_GID" != "1000" ] || [ "$USER_UID" != "1000" ]; then \
groupmod --gid $USER_GID $USERNAME \
&& usermod --uid $USER_UID --gid $USER_GID $USERNAME \
&& chmod -R $USER_UID:$USER_GID /home/$USERNAME \
&& chmod -R $USER_UID:root /usr/local/share/nvm /usr/local/share/npm-global; \
fi
# Set the Chrome repo.
RUN wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - \
&& echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list
# Install Chrome.
RUN apt-get update && apt-get -y install google-chrome-stable \
&& rm -rf /var/lib/apt/lists/*
# ** [Optional] Uncomment this section to install additional packages. **
#
# RUN apt-get update \
# && export DEBIAN_FRONTEND=noninteractive \
# && apt-get -y install --no-install-recommends
ts-loader-9.4.2/.devcontainer/devcontainer.json 0000664 0000000 0000000 00000002070 14341700417 0021533 0 ustar 00root root 0000000 0000000 // For format details, see https://aka.ms/vscode-remote/devcontainer.json or this file's README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.122.1/containers/typescript-node-14
{
"name": "ts-loader devcontainer",
"dockerFile": "Dockerfile",
// Set *default* container specific settings.json values on container create.
"settings": {
"terminal.integrated.profiles.linux": {
"zsh": {
"path": "/bin/zsh",
"icon": "terminal-bash"
}
},
"terminal.integrated.defaultProfile.linux": "zsh",
},
// Add the IDs of extensions you want installed when the container is created.
"extensions": [
"dbaeumer.vscode-eslint",
"esbenp.prettier-vscode"
],
// Use 'forwardPorts' to make a list of ports inside the container available locally.
"forwardPorts": [/* for debugging execution tests */ 9876],
// Use 'postCreateCommand' to run commands after the container is created.
"postCreateCommand": "yarn install",
// Uncomment to connect as a non-root user. See https://aka.ms/vscode-remote/containers/non-root.
// "remoteUser": "node"
} ts-loader-9.4.2/.dockerignore 0000664 0000000 0000000 00000000072 14341700417 0016074 0 ustar 00root root 0000000 0000000 .devcontainer
.github
.vscode
.test
node_modules
examples
ts-loader-9.4.2/.eslintignore 0000664 0000000 0000000 00000000033 14341700417 0016120 0 ustar 00root root 0000000 0000000 /.test/**
/dist/**
/test/** ts-loader-9.4.2/.eslintrc.js 0000664 0000000 0000000 00000002466 14341700417 0015670 0 ustar 00root root 0000000 0000000 module.exports = {
root: true,
parser: '@typescript-eslint/parser',
extends: ['plugin:node/recommended'/*, 'plugin:prettier/recommended'*/],
parserOptions: {
ecmaVersion: 2018,
sourceType: 'module',
},
settings: {
node: {
tryExtensions: ['.js', '.json', '.ts', '.d.ts'],
},
},
rules: {
// 'no-process-exit': 'off', // to investigate if we should throw an error instead of process.exit()
// 'node/no-unsupported-features/es-builtins': 'off',
},
overrides: [
{
files: ['*.ts'],
extends: [
'plugin:@typescript-eslint/recommended', // Uses the recommended rules from the @typescript-eslint/eslint-plugin
'prettier', // Uses eslint-config-prettier to disable ESLint rules from @typescript-eslint/eslint-plugin that would conflict with prettier
],
rules: {
'node/no-unsupported-features/es-syntax': 'off',
'@typescript-eslint/explicit-module-boundary-types': 'off',
'@typescript-eslint/no-non-null-assertion': 'off',
'@typescript-eslint/no-explicit-any': 'off',
'@typescript-eslint/no-unused-vars': 'off',
// '@typescript-eslint/explicit-function-return-type': 'off',
// '@typescript-eslint/no-namespace': 'off' // maybe we should consider enabling it in the future
},
},
],
};
ts-loader-9.4.2/.gitattributes 0000664 0000000 0000000 00000000073 14341700417 0016314 0 ustar 00root root 0000000 0000000 *.ts eol=lf
*.js eol=lf
test/** linguist-detectable=false
ts-loader-9.4.2/.github/ 0000775 0000000 0000000 00000000000 14341700417 0014761 5 ustar 00root root 0000000 0000000 ts-loader-9.4.2/.github/FUNDING.yml 0000664 0000000 0000000 00000000106 14341700417 0016573 0 ustar 00root root 0000000 0000000 # These are supported funding model platforms
github: [johnnyreilly]
ts-loader-9.4.2/.github/issue_template.md 0000664 0000000 0000000 00000000224 14341700417 0020324 0 ustar 00root root 0000000 0000000 ### Expected Behaviour
### Actual Behaviour
### Steps to Reproduce the Problem
### Location of a Minimal Repository that Demonstrates the Issue.
ts-loader-9.4.2/.github/stale.yml 0000664 0000000 0000000 00000001360 14341700417 0016614 0 ustar 00root root 0000000 0000000 # Number of days of inactivity before an issue becomes stale
daysUntilStale: 60
# Number of days of inactivity before a stale issue is closed
daysUntilClose: 7
# Issues with these labels will never be considered stale
exemptLabels:
- pinned
- security
# Label to use when marking an issue as stale
staleLabel: wontfix
# Comment to post when marking an issue as stale. Set to `false` to disable
markComment: >
This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs. Thank you
for your contributions.
# Comment to post when closing a stale issue. Set to `false` to disable
closeComment: >
Closing as stale. Please reopen if you'd like to work on this further. ts-loader-9.4.2/.github/workflows/ 0000775 0000000 0000000 00000000000 14341700417 0017016 5 ustar 00root root 0000000 0000000 ts-loader-9.4.2/.github/workflows/push.yml 0000664 0000000 0000000 00000005415 14341700417 0020525 0 ustar 00root root 0000000 0000000 name: build and test
on: [push, pull_request]
jobs:
comparison_test_ubuntu:
name: Comparison Tests Ubuntu
runs-on: ubuntu-latest
timeout-minutes: 25
steps:
- uses: actions/checkout@v2
- name: install
run: yarn install
- name: build
run: yarn build
- name: test
run: sudo yarn comparison-tests
comparison_test_windows:
name: Comparison Tests Windows
runs-on: windows-latest
timeout-minutes: 25
steps:
- uses: actions/checkout@v2
- name: copy files
shell: pwsh
run: |
New-Item C:\source\ts-loader -ItemType Directory
Copy-Item .\* C:\source\ts-loader -Recurse -Force
- name: install
run: yarn install
working-directory: C:\source\ts-loader
- name: build
run: yarn build
working-directory: C:\source\ts-loader
- name: test
run: yarn comparison-tests
working-directory: C:\source\ts-loader
execution_test_ubuntu:
name: Execution Tests Ubuntu
strategy:
matrix:
node: [14, 16]
ts: [3.8.3, 3.9.3, 4.0.3, 4.1.5, 4.2.4, 4.3.2, 4.4.2, 4.5.2, 4.6.2, 4.7.3, 4.8.2, 4.9.3, next]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: install node
uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node }}
- name: install
run: yarn install
- name: build
run: yarn build
- name: install typescript
run: yarn add typescript@${{ matrix.ts }}
- name: test
run: yarn execution-tests
execution_test_windows:
name: Execution Tests Windows
strategy:
matrix:
node: [14, 16]
ts: [3.8.3, 3.9.3, 4.0.3, 4.1.5, 4.2.4, 4.3.2, 4.4.2, 4.5.2, 4.6.2, 4.7.3, 4.8.2, 4.9.3, next]
runs-on: windows-latest
steps:
- uses: actions/checkout@v2
- name: install node
uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node }}
- name: copy files
shell: pwsh
run: |
New-Item C:\source\ts-loader -ItemType Directory
Copy-Item .\* C:\source\ts-loader -Recurse -Force
- name: install
run: yarn install
working-directory: C:\source\ts-loader
- name: build
run: yarn build
working-directory: C:\source\ts-loader
- name: install typescript
run: yarn add typescript@${{ matrix.ts }}
working-directory: C:\source\ts-loader
- name: test
run: yarn execution-tests
working-directory: C:\source\ts-loader
lint:
name: Lint
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: install
run: yarn install
- name: lint
run: yarn lint
ts-loader-9.4.2/.github/workflows/release.yml 0000664 0000000 0000000 00000001055 14341700417 0021162 0 ustar 00root root 0000000 0000000 on:
release:
types: [published]
name: release
jobs:
build_test_and_publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: install node
uses: actions/setup-node@v1
with:
node-version: 16
registry-url: https://registry.npmjs.org/
- name: install
run: yarn install
- name: build
run: yarn build
- name: test
run: yarn execution-tests
- run: npm publish
env:
NODE_AUTH_TOKEN: ${{secrets.NPM_AUTH_TOKEN}}
ts-loader-9.4.2/.gitignore 0000664 0000000 0000000 00000000471 14341700417 0015413 0 ustar 00root root 0000000 0000000 /*.js
!index.js
/src/*.js
/src/.vscode
/*.d.ts
/*.log
*.js.map
bundle.js
npm-debug.log
/.test/
/test/execution-tests/**/typings
!/test/**/expectedOutput-*/**
/**/node_modules
/dist
/test/execution-tests/**/dist
/**/.happypack
/**/.cache-loader
!build.js
/**/debug.log
.pnp
.pnp.js
!.eslintrc.js
.vs/**
.pnpm-store ts-loader-9.4.2/.npmignore 0000664 0000000 0000000 00000000264 14341700417 0015422 0 ustar 00root root 0000000 0000000 .devcontainer
.vscode
.test
examples
test
src
.pnpm-store
.github
.dockerignore
.gitattributes
.travis.yml
appveyor.yml
CONTRIBUTING.md
Dockerfile
HISTORY.md
RELEASING.md
*.js.map
ts-loader-9.4.2/.prettierignore 0000664 0000000 0000000 00000000010 14341700417 0016453 0 ustar 00root root 0000000 0000000 /test/** ts-loader-9.4.2/.prettierrc 0000664 0000000 0000000 00000000210 14341700417 0015576 0 ustar 00root root 0000000 0000000 {
"arrowParens": "avoid",
"singleQuote": true,
"semi": true,
"tabWidth": 2,
"useTabs": false,
"printWidth": 80
} ts-loader-9.4.2/.vscode/ 0000775 0000000 0000000 00000000000 14341700417 0014762 5 ustar 00root root 0000000 0000000 ts-loader-9.4.2/.vscode/extensions.json 0000664 0000000 0000000 00000000131 14341700417 0020047 0 ustar 00root root 0000000 0000000 {
"recommendations": [
"dbaeumer.vscode-eslint",
"esbenp.prettier-vscode"
]
} ts-loader-9.4.2/.vscode/launch.json 0000664 0000000 0000000 00000001665 14341700417 0017137 0 ustar 00root root 0000000 0000000 {
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Run open execution test",
"runtimeExecutable": "npm",
"runtimeArgs": [
"run",
"execution-tests",
"--",
"--single-test",
"${fileDirname}",
"--debug"
],
"console": "integratedTerminal",
"port": 5858
},
{
"type": "node",
"request": "launch",
"name": "Run open comparison test",
"runtimeExecutable": "npm",
"runtimeArgs": [
"run",
"comparison-tests",
"--",
"--single-test",
"${fileDirname}",
"--debug"
],
"console": "integratedTerminal",
"port": 5858
}
]
} ts-loader-9.4.2/.vscode/settings.json 0000664 0000000 0000000 00000000123 14341700417 0017511 0 ustar 00root root 0000000 0000000 {
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
} ts-loader-9.4.2/CHANGELOG.md 0000664 0000000 0000000 00000101502 14341700417 0015231 0 ustar 00root root 0000000 0000000 # Changelog
## 9.4.2
* [Bug fix: Use custom transformer when building solution references](https://github.com/TypeStrong/ts-loader/pull/1550) [#1025] - thanks @feosuna1
## 9.4.1
* [Hotfix: Disable `enhanced-resolve`](https://github.com/TypeStrong/ts-loader/pull/1505) - thanks @manuth
## v9.4.0
* [Add Support for Resolving `.cjs`, `.mjs`, `.cts` and `.mts` Files](https://github.com/TypeStrong/ts-loader/pull/1503) [#1503] - thanks @manuth
## v9.3.1
* [Bug fix: Generate declaration files for js files if allowJs is set to true](https://github.com/TypeStrong/ts-loader/pull/1483) [#1260] - thanks @hediet and @mvilliger
## v9.3.0
* [simplify configuration for fork-ts-checker-webpack-plugin](https://github.com/TypeStrong/ts-loader/pull/1451) - thanks @piotr-oles
## v9.2.9
* [make v9 latest following v8 release](https://github.com/TypeStrong/ts-loader/pull/1447) - thanks @johnnyreilly
## v9.2.8
* [Bug fix: support webpack 5 in ts-loader](https://github.com/TypeStrong/ts-loader/pull/1439) [#1438] - thanks @einatbar
## v9.2.7
* [cater for change in resolveTypeReferenceDirective API in TypeScript 4.7](https://github.com/TypeStrong/ts-loader/pull/1422) [#1421] - thanks @johnny_reilly and @cspotcode for inspiration in ts-node work here: https://github.com/TypeStrong/ts-node/pull/1648
## v9.2.6
* [Docs fix for thread-loader / history](https://github.com/TypeStrong/ts-loader/pull/1377) - thanks @johnnyreilly
## v9.2.5
* [Add function to get the latest program](https://github.com/TypeStrong/ts-loader/pull/1352) - thanks @Zn4rK
## v9.2.4
* [Fix undefined configPath now falls back to default](https://github.com/TypeStrong/ts-loader/pull/1346) - thanks @johnnyreilly
## v9.2.3
* [Fix error message for invalid getCustomTransformers modules](https://github.com/TypeStrong/ts-loader/issues/1334) - thanks @blaky
## v9.2.2
* [Start consuming webpack loader types](https://github.com/TypeStrong/ts-loader/issues/1325) - thanks @johnnyreilly
* [Add webpack minimum version in peerDependencies](https://github.com/TypeStrong/ts-loader/issues/1324) - thanks @afdev82
## v9.2.1
* [Make v9 latest in npm again](https://github.com/TypeStrong/ts-loader/issues/1320) - thanks @johnnyreilly
## v9.2.0
* [Fixed impossibility to have several instances of ts-loader with different compiler options](https://github.com/TypeStrong/ts-loader/issues/1316) - thanks @timocov
## v9.1.2
* [Fix removed files handling in watch mode](https://github.com/TypeStrong/ts-loader/pull/1293) - thanks @gasnier
## v9.1.1
* [update CHANGELOG.md for 8.2.0 release](https://github.com/TypeStrong/ts-loader/pull/1291) - thanks @johnnyreilly
## v9.1.0
* [Use caches for module resolution and type reference directives when using compiler default functions](https://github.com/TypeStrong/ts-loader/pull/1287) - thanks @sheetalkamat - uses: https://github.com/microsoft/TypeScript/pull/43700
## v9.0.2
* [Remove usage of loader-utils](https://github.com/TypeStrong/ts-loader/pull/1288) - thanks @jonwallsten
## v9.0.1
* [Use correct hook for emitting additional assets during compilation](https://github.com/TypeStrong/ts-loader/pull/1286) - thanks @jonwallsten
## v9.0.0
Breaking changes:
- minimum webpack version: 5
- minimum node version: 12
Changes:
* [webpack 5 migration](https://github.com/TypeStrong/ts-loader/pull/1251) - thanks @johnnyreilly, @jonwallsten, @sokra, @appzuka, @alexander-akait
## v8.4.0
* [fix: cater for change in resolveTypeReferenceDirective API in 4.7](https://github.com/TypeStrong/ts-loader/pull/1446) - thanks @dragomirtitian
* This is a backport from v9.2.7 for webpack 4 compatibility
## v8.3.0
* [Fixed impossibility to have several instances of ts-loader with different compiler options](https://github.com/TypeStrong/ts-loader/issues/1316) - thanks @timocov
* This is a backport from v9.2.0 for webpack 4 compatibility
## v8.2.0
* [Use caches for module resolution and type reference directives when using compiler default functions](https://github.com/TypeStrong/ts-loader/pull/1287) - thanks @sheetalkamat - uses: https://github.com/microsoft/TypeScript/pull/43700
* This is a backport from v9.1.0 for webpack 4 compatibility
## v8.1.0
* [feat: remove top-level typescript import statements](https://github.com/TypeStrong/ts-loader/pull/1259) - thanks @ulivz
## v8.0.18
* [Perf: Optimize fileExists callback path](https://github.com/TypeStrong/ts-loader/issues/1266) - thanks @berickson1
## v8.0.17
* [Included correct webpack source location in emitted errors](https://github.com/TypeStrong/ts-loader/issues/1199) - thanks @lorenzodallavecchia
## v8.0.16
* [Re-Fixed missing errors in watch mode in webpack5](https://github.com/TypeStrong/ts-loader/issues/1204) - thanks @appzuka
## v8.0.15
* [Update definition files in watch mode in webpack@5](https://github.com/TypeStrong/ts-loader/pull/1249) - thanks @appzuka,@JonWallsten,@alexander-akait
* [Add afterDeclarations to getCustomTransformers in README.md](https://github.com/TypeStrong/ts-loader/pull/1248) - thanks @appzuka
## v8.0.14
* [Upgrade `chalk`, `loader-utils`, and `semver` to latest stable versions](https://github.com/TypeStrong/ts-loader/pull/1237) - thanks Avi Vahl
## v8.0.13
* [Speed up builds by adding an in-memory cache to file path lookups](https://github.com/TypeStrong/ts-loader/pull/1228) - thanks @berickson1
## v8.0.12
* [Instead of checking date, check time thats more accurate to see if something has changed](https://github.com/TypeStrong/ts-loader/pull/1217) - thanks @sheetalkamat
## v8.0.11
* [Fixed build failing in yarn v2 pnp](https://github.com/TypeStrong/ts-loader/pull/1209) - thanks @aicest
## v8.0.10
* [Fixed missing errors in watch mode in webpack5](https://github.com/TypeStrong/ts-loader/issues/1204) - thanks @appzuka
## v8.0.9
* [Fixed build failing when using thread-loader](https://github.com/TypeStrong/ts-loader/pull/1207) - thanks @valerio
## v8.0.8
* [Fixed memory leak when using multiple webpack instances](https://github.com/TypeStrong/ts-loader/pull/1205) - thanks @valerio
## v8.0.7
* [Speeds up project reference build and doesnt store the result in memory](https://github.com/TypeStrong/ts-loader/pull/1202) - thanks @sheetalkamat
## v8.0.6
* [Fixed further deprecation warning on webpack@5](https://github.com/TypeStrong/ts-loader/issues/1196) - thanks @appzuka
## v8.0.5
* [Fixed deprecation warnings on webpack@5](https://github.com/TypeStrong/ts-loader/issues/1194) - thanks @sanex3339
## v8.0.4
* [Uses existing instance if config file is same as already built solution](https://github.com/TypeStrong/ts-loader/pull/1177) - thanks @sheetalkamat
## v8.0.3
* [Fix the wrong instance caching when using `appendTsSuffixTo` and `appendTsxSuffixTo` together](https://github.com/TypeStrong/ts-loader/pull/1170) - thanks @meowtec
## v8.0.2
* [Fix 2 issues with experimentalWatchApi](https://github.com/TypeStrong/ts-loader/pull/1159) - thanks @appzuka
## v8.0.1
* [Fix webpack deprecations](https://github.com/TypeStrong/ts-loader/pull/1135) - thanks @g-plane
## v8.0.0
* [Support for symlinks in project references](https://github.com/TypeStrong/ts-loader/pull/1136) - thanks @sheetalkamat!
* `ts-loader` now supports TypeScript 3.6 and greater **BREAKING CHANGE**
## v7.0.5
* [Add a delay before starting the comparison tests to avoid failures under WSL](https://github.com/TypeStrong/ts-loader/pull/1109) - thanks @appzuka
* [Apply other loaders when updating files in watch mode](https://github.com/TypeStrong/ts-loader/pull/1115) - thanks @iorate
## v7.0.4
* [Ensure a separate webpack instance is created for different loader options](https://github.com/TypeStrong/ts-loader/pull/1104) - thanks @appzuka
## v7.0.3
* [Ensure that JSON files are included in build module resolution](https://github.com/TypeStrong/ts-loader/pull/1101) - thanks @berickson1
## v7.0.2
* [Make content hash consistent across machines](https://github.com/TypeStrong/ts-loader/pull/1085) - thanks @elyalvarado
## v7.0.1
* [fix: watch-run](https://github.com/TypeStrong/ts-loader/pull/1083) - thanks @zn4rk
## v7.0.0
* [Project reference support enhancements](https://github.com/TypeStrong/ts-loader/pull/1076) - thanks @sheetalkamat!
* Following the end of life of Node 8, `ts-loader` no longer supports Node 8 **BREAKING CHANGE**
## v6.2.2
* [Enable typescript 3.8.3 support when using `webpack.config.ts` files](https://github.com/TypeStrong/ts-loader/issues/1072) - thanks @vladimiry!
## v6.2.1
* [Output types alongside JS files, enable declaration maps](https://github.com/TypeStrong/ts-loader/pull/1026) - thanks @meyer!
## v6.2.0
* [Emitting .tsbuildinfo when using watch api](https://github.com/TypeStrong/ts-loader/pull/1017) - thanks @sheetalkamat!
## v6.1.2
* [don't emit declaration files for a declaration file](https://github.com/TypeStrong/ts-loader/pull/1015) (#1014) - thanks @gvinaccia!
* [Consume typescript apis from typescript nightly](https://github.com/TypeStrong/ts-loader/pull/1016) - thanks @sheetalkamat!
## v6.1.1
* [Fix SolutionBuilder watches](https://github.com/TypeStrong/ts-loader/pull/1003) and [related fixes](https://github.com/TypeStrong/ts-loader/pull/1011) (#998) - thanks @sheetalkamat!
* [fix: no errors reported if flagged with @ts-check](https://github.com/TypeStrong/ts-loader/pull/1008) (#1004) - thanks @reinholdk!
## v6.1.0
* [Build upstream project references with SolutionBuilder](https://github.com/TypeStrong/ts-loader/pull/935) (#851, #913) - thanks @sheetalkamat!
## v6.0.4
* [Fix issue when handling files not included in tsconfig.json](https://github.com/TypeStrong/ts-loader/issues/943) (#934) - thanks @davazp!
## v6.0.3
* [Upgrade typescript version to 3.5.2](https://github.com/TypeStrong/ts-loader/pull/954) (#954) - thanks @fa93hws
## v6.0.2
* [Set configFilePath when reading config file](https://github.com/TypeStrong/ts-loader/pull/942) (#939) - thanks @konpikwastaken!
## v6.0.1
* [Fix issue with `resolveTypeReferenceDirective` causing errors like `Cannot find name 'it'` with Jest](https://github.com/TypeStrong/ts-loader/pull/936) (#934) (#919) - thanks @andrewbranch!
* [Fix TypeScript diagnostics not being printed to console when using project references](https://github.com/TypeStrong/ts-loader/pull/937) (#932) - thanks @andrewbranch!
## v6.0.0
* [Drop support for node < 8.6 related to micromatch upgrade to 4](https://github.com/TypeStrong/ts-loader/pull/930); see: https://github.com/TypeStrong/ts-loader/issues/929
* [Update dependencies](https://github.com/TypeStrong/ts-loader/pull/928) - thanks @johnnyreilly!
## v5.4.5
* [use @types/webpack for loader typings](https://github.com/TypeStrong/ts-loader/pull/927) - thanks @LukeSheard!
## v5.4.4
* [refactor: add common appendTsTsxSuffixesIfRequired function to instance](https://github.com/TypeStrong/ts-loader/pull/924) - thanks @johnnyreilly!
## v5.4.3
* [feat: resolveTypeReferenceDirective support for yarn PnP](https://github.com/TypeStrong/ts-loader/pull/921) - thanks @johnnyreilly!
* [fix: don't include anything apart from ts-loader in publish](https://github.com/TypeStrong/ts-loader/pull/923) - thanks @johnnyreilly!
## v5.3.3
* [fix: Pass ts.Program to getCustomTransformers](https://github.com/TypeStrong/ts-loader/pull/889) (#860) - thanks @andersekdahl!
## v5.3.2
* [feat: enable experimentalFileCaching by default](https://github.com/TypeStrong/ts-loader/pull/885) (#868) - thanks @timocov!
## v5.3.1
* [fix: projectReferences with rootDir](https://github.com/TypeStrong/ts-loader/pull/871) (#868) - thanks @andrewbranch!
## v5.3.0
* [feat: Exposes a `resolveNodeModule` option](https://github.com/TypeStrong/ts-loader/pull/862) - thanks @arcanis!
## v5.2.2
* [feat: Micro-optimizations](https://github.com/TypeStrong/ts-loader/pull/855) - thanks @johnnyreilly
## v5.2.1
* [feat: Lists typescript as a peer dependency](https://github.com/TypeStrong/ts-loader/pull/841) - thanks @arcanis!
## v5.2.0
* [feat: Initial support for project references - `projectReferences`](https://github.com/TypeStrong/ts-loader/pull/817) - thanks @andrewbranch!
## v5.1.1
* [fix(getTranspilationEmit): pass the raw path to transpileModule](https://github.com/TypeStrong/ts-loader/pull/835) - thanks @Brooooooklyn
## v5.1.0
* [feat: Added cache for some FS operations while compiling - `experimentalFileCaching`](https://github.com/TypeStrong/ts-loader/pull/829) - thanks @timocov!
## v5.0.0
* [feat: Fixed issue with incorrect output path for declaration files](https://github.com/TypeStrong/ts-loader/pull/822) - thanks @JonWallsten! **BREAKING CHANGE**
## v4.5.0
* [feat: Added support for TypeScript declaration map](https://github.com/TypeStrong/ts-loader/pull/821) - thanks @JonWallsten!
## v4.4.2
* [fix(loader): new Error to webpack when errors occured in the loader function](https://github.com/TypeStrong/ts-loader/pull/792) - thanks @linxiaowu66 and @systemmetaphor!
## v4.4.1
* [fix(types): expose public interfaces from root index.d.ts](https://github.com/TypeStrong/ts-loader/pull/790) - thanks @Hotell!
## v4.4.0
* [feat: generate ambient types from implementation](https://github.com/TypeStrong/ts-loader/pull/788) - thanks @Hotell!
* [error when not using webpack 4](https://github.com/TypeStrong/ts-loader/pull/786) - thanks @johnnyreilly
## v4.3.1
* [Fix options caching when ts-loader is used in multiple rules](https://github.com/TypeStrong/ts-loader/pull/782) - thanks @yyx990803!
Please note, this bug fix requires that vue-loader users still using v14 should either upgrade to v15 or explicitly pass the same ts-loader options via v14's loaders option. [See more details here](https://github.com/TypeStrong/ts-loader/pull/782#issuecomment-394406093)
## v4.3.0
* [Fix dependency resolution when using pnpm](https://github.com/TypeStrong/ts-loader/pull/774) - thanks @xbtsw and @zkochan!
* [Add `allowTsInNodeModules` option for importing .ts files from node_modules](https://github.com/TypeStrong/ts-loader/pull/773) - thanks @aelawson!
## v4.2.0
* [Pass `context' to error formatters](https://github.com/TypeStrong/ts-loader/pull/756) - thanks @gustavderdrache!
## v4.1.0
* [Fix slow `experimentalWatchApi`](https://github.com/TypeStrong/ts-loader/pull/747) (#746) - thanks @sheetalkamat and @MLoughry!
* [feat: `getCustomTransformers` support path string for a module](https://github.com/TypeStrong/ts-loader/pull/745) - thanks @vagusX and @s-panferov (upon whose work this is based I believe)
## v4.0.1
* [Fix name collision in experimentalWatchApi code](https://github.com/TypeStrong/ts-loader/pull/737) - thanks @MLoughry!
## v4.0.0
* Support webpack 4
* Drop support for webpack 2/3 **BREAKING CHANGE** - use ts-loader 3.x if you need webpack 2/3 support
* Minimum TypeScript version is now 2.4.1 **BREAKING CHANGE**
* Deprecated option `entryFileCannotBeJs` removed' **BREAKING CHANGE**
* Start using [prettier](https://prettier.io/) for the codebase
## v3.5.0
* [Add trace for traceResolution](https://github.com/TypeStrong/ts-loader/pull/721) - thanks @onigoetz!
## v3.4.0
* [local .d.ts files now marked as changed when watch is triggered](https://github.com/TypeStrong/ts-loader/pull/698) - thanks @KnisterPeter!
## v3.3.1
* [Fixes to support watch api for compiling - lib support etc](https://github.com/TypeStrong/ts-loader/pull/715) - thanks @sheetalkamat!
## v3.3.0
* [Report diagnostics only on certain files with `reportFiles` option](https://github.com/TypeStrong/ts-loader/pull/701) - thanks @freeman!
* [Replaced option `contextAsConfigBasePath` with `context` option.](https://github.com/TypeStrong/ts-loader/pull/688/) Strictly speaking a breaking change. However, given the original option was never able to fulfil its intended purpose I've decided to treat this as just a new feature; there seems no possibility that anyone can be using `contextAsConfigBasePath` - thanks @christiantinauer!
* [Added support for the new watch api of TypeScript compiler.](https://github.com/TypeStrong/ts-loader/pull/685) nb This feature has been placed behind a new `experimentalWatchApi` option until it has been thoroughly tested. All being well it is likely to become the default behaviour for ts-loader in future - thanks @sheetalkamat!
## v3.2.0
* [Add new loader option `contextAsConfigBasePath`](https://github.com/TypeStrong/ts-loader/pull/681) - thanks @christiantinauer
## v3.1.1
* [Fix error importing buildt ts files with allowJs](https://github.com/TypeStrong/ts-loader/pull/674) (#667) - thanks @Pajn!
## v3.1.0
* [Add `onlyCompileBundledFiles` option which modifies behaviour to load only those files that are actually bundled by webpack](https://github.com/TypeStrong/ts-loader/pull/671) #267 - thanks @maier49!
* [Chore release; upgraded chalk dependency in `package.json` to 2.3, as 2.3 is another breaking changes release (from a TypeScript perspective).](https://github.com/TypeStrong/ts-loader/issues/664), see [here](https://github.com/chalk/chalk/issues/215) for context - thanks @johnnyreilly
## v3.0.5
* [Chore release; upgraded chalk dependency in `package.json` to 2.2, as 2.2 appears to be a breaking changes release.](https://github.com/TypeStrong/ts-loader/issues/664) - thanks @lmk123 for reporting
## v3.0.4
* [Chore release; upgraded chalk dependency.](https://github.com/TypeStrong/ts-loader/pull/662) - thanks @johnnyreilly
## v3.0.3
* [Fix allowJs @types resolution error](https://github.com/TypeStrong/ts-loader/pull/658) (#657, #655) - thanks @johnnyreilly and @roddypratt + @ldrick for providing minimal repro repos which allowed me to fix this long standing bug!
This fix resolves the issue for TypeScript 2.4+ (which is likely 95% of users). For those people stuck on 2.3 or below and impacted by this issue, you should be able to workaround this by setting `entryFileCannotBeJs: true` in your ts-loader options. This option should be considered deprecated as of this release. The option will likely disappear with the next major version of ts-loader which will drop support for TypeScript 2.3 and below, thus removing the need for this option.
## v3.0.0
All changes were made with this [PR](https://github.com/TypeStrong/ts-loader/pull/643) - thanks @johnnyreilly
([Published to npm as v3.0.2 due to npm publishing issues](https://github.com/TypeStrong/ts-loader/issues/654)) thanks @mattlewis92 for noticing!
* drop support for typescript < 2.0 (no-one seems to be using it and we can simplify the code) **BREAKING CHANGE**
* remove `entryFileIsJs` option; it can be inferred from whether the `allowJs` TypeScript compiler option has been set.
* move to webpack 3.0 for test harness
* drop `configFileName` support [(replaced by `configFile`)](https://github.com/TypeStrong/ts-loader/pull/607) **BREAKING CHANGE**
* add support for a custom formatter for output - drop visual studio format (this can be added back if there's clamour for it and people can supply their own formatters in the interim) **BREAKING CHANGE**
* make loglevel warn by default (stop outputting typescript version number by default). Fixes [#488](https://github.com/TypeStrong/ts-loader/issues/488)
* fix [tsc has "module" default to "es2015"when targetting es2015+, but ts-loader does not](https://github.com/TypeStrong/ts-loader/issues/570) - thanks [@Venryx](https://github.com/Venryx) for the suggestion!
* [switch to build ts-loader / run tests with yarn](https://github.com/TypeStrong/ts-loader/issues/369) because of [this](https://stackoverflow.com/questions/45022048/why-does-npm-install-rewrite-package-lock-json/45566871#45566871)
* allow controlling whether the output can contain colours
## v2.3.7
* [Start validating the options supplied to the loader](https://github.com/TypeStrong/ts-loader/pull/630) (#629) - thanks @johnnyreilly!
## v2.3.6
* [Fix kills ts-loader dependant builds issue](https://github.com/TypeStrong/ts-loader/pull/627) (#626) - thanks @Loilo!
## v2.3.5
* [Add an additional check for js files before reusing isExternalLibaryImport](https://github.com/TypeStrong/ts-loader/pull/622) (#620) - thanks @WillMartin!
* [Make TypeScript `basePath` configurable](https://github.com/TypeStrong/ts-loader/pull/621) (#618) - thanks @Loilo!
* [Fix relative configFile path](https://github.com/TypeStrong/ts-loader/pull/618) (#617) - thanks @Loilo!
## v2.3.4
* [Add `configFile` option](https://github.com/TypeStrong/ts-loader/pull/607) - thanks @Loilo!
## v2.3.3
* [fix(tsconfig): stop passing rootDir option to TypeScript compiler](https://github.com/TypeStrong/ts-loader/pull/598) (#597) - thanks @Brooooooklyn
* [Fix findConfigFile in Windows](https://github.com/TypeStrong/ts-loader/pull/605) (#604) - thanks @mengxy
## v2.3.2
* [Move to use strictNullChecks](https://github.com/TypeStrong/ts-loader/pull/589) - thanks @johnnyreilly
* [`allowJs` supports importing types from external libraries](https://github.com/TypeStrong/ts-loader/pull/590) (#586, #577) - thanks @bsouthga!
## v2.3.1
* [Fix undefined watcher in watch-run causes error](https://github.com/TypeStrong/ts-loader/pull/587) (#585) - thanks @zinserjan and @sokra!
## v2.3.0
* [add appendTsxSuffixTo option to support using tsx with Vue](https://github.com/TypeStrong/ts-loader/pull/581) - lots of discussion went into this PR. Thanks to @vhqtvn (author) and @HerringtonDarkholme, @johnnyreilly, @jbrantly, @octref, @rhyek and others for helping us land on our final implementation.
* [refactor: Use chalk instead of colors](https://github.com/TypeStrong/ts-loader/pull/579) - thanks @develar!
## v2.2.2
* [Remove default of setting isolatedModules to true when in transpileOnly mode](https://github.com/TypeStrong/ts-loader/pull/569) - thanks @johnnyreilly and @donaldpipowitch
## v2.2.1
* [Report errors in JS(X) files when CheckJS is enabled](https://github.com/TypeStrong/ts-loader/pull/564) - thanks @schmuli!
* [Cater for change to @types acquisition strategy in TypeScript 2.4.1](https://github.com/TypeStrong/ts-loader/pull/566) - thanks @johnnyreilly
## v2.2.0
* [Support custom transformers for ts](https://github.com/TypeStrong/ts-loader/pull/535) - thanks @longlho and @Igorbek!
## v2.1.0
* [Add happypack compatibility mode](https://github.com/TypeStrong/ts-loader/pull/547) - thanks @aindlq!
## v2.0.3
* [Don't include appended TS extension in webpack dependencies](https://github.com/TypeStrong/ts-loader/pull/497) - thanks again @wearymonkey!
## v2.0.2
* [Fix performance regression related to using getTimes() by tracking timestamps](https://github.com/TypeStrong/ts-loader/pull/500) - thanks @wearymonkey
## v2.0.1
* [make watch resilient to no watcher / watcher.mtimes](https://github.com/TypeStrong/ts-loader/pull/482) - thanks @bancek and @mredbishop
* [move to using loader-utils 1.0](https://github.com/TypeStrong/ts-loader/pull/475)
## v2.0.0
* [Add support for IgnoringWatchFileSystem](https://github.com/TypeStrong/ts-loader/pull/444) - thanks @herschel666
* [Use native Object.assign()](https://github.com/TypeStrong/ts-loader/pull/418) - thanks @arusakov
Breaking changes:
* ts-loader now officially only supports webpack 2. ts-loader 2.x may work with webpack 1 but it is not supported. Related to that, all continuous integration tests now run against webpack 2.
* as webpack 2 does not support node 0.12 neither does ts-loader from now. node 4 at least is required.
## v1.3.3
* [Fix bug when "extend"ing a tsconfig that specifies "allowJs"](https://github.com/TypeStrong/ts-loader/pull/415) Thanks @cspotcode
* [Minor perf optimisations](https://github.com/TypeStrong/ts-loader/pull/412)
## v1.3.2
* [Upgrade enhanced-resolve to v3](https://github.com/TypeStrong/ts-loader/pull/411)
* [Remove arrify dependency](https://github.com/TypeStrong/ts-loader/pull/410)
## v1.3.1
* [Rolled back re-exported const enums no longer break emit in watch mode as performance cost was too high](https://github.com/TypeStrong/ts-loader/pull/406) resolves #393
## v1.3.0
* [Introduce meaningful error when importing TypeScript from `node_modules`](https://github.com/TypeStrong/ts-loader/pull/399)
* [Introduce `entryFileIsJs` loader option which allows having an entry file which is js.](https://github.com/TypeStrong/ts-loader/pull/399) resolves #388 and #401 - thanks @Wykks and @pqr.
NB Previously the `entryFileIsJs` option was on by default when `allowJs` was true. Now it has to be specified directly. Strictly speaking this is a breaking change; however given this is a rarely used option which exists for what is arguably an edge case this is being added without moving to 2.0. If this breaks people then we'll never do this again; I'd be surprised if anyone is relying on this though so we're taking a chance. Related tests have been suffixed "-entryFileIsJs" in the test name.
## v1.2.2
* [Re-exported const enums no longer break emit in watch mode](https://github.com/TypeStrong/ts-loader/pull/377) [#376] - thanks @smphhh
* [typescript.sys should be compiler.sys](https://github.com/TypeStrong/ts-loader/pull/380) [#379] - thanks @johnnyreilly and @jbrantly
## v1.2.1
* [Fix TS module resolution paths on Windows - watch mode becomes faster](https://github.com/TypeStrong/ts-loader/pull/373) [#372] - thanks @smphhh
## v1.2.0
* [Crash when adding/removing files in watch-mode](https://github.com/TypeStrong/ts-loader/pull/364) [#358] - thanks @jbbr for the suggested fix
* [Provided an option to produce Visual Studio compatible error output](https://github.com/TypeStrong/ts-loader/pull/356) [#355] - thanks @gamli
## v1.1.0
* [Added support for vuejs via `appendTsSuffixTo` option](https://github.com/TypeStrong/ts-loader/pull/354) [#270] - thanks @HerringtonDarkholme
## 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
* [Improve performance for watch mode / `after-compile` plugin](https://github.com/TypeStrong/ts-loader/pull/187) - thanks @Strate
## v0.9.4
* [Make logging to stderr or stdout configurable; introduce logging levels](https://github.com/TypeStrong/ts-loader/pull/313) [#214] - thanks @ThYpHo0n
* [Fix regression that broke hot module replacement](https://github.com/TypeStrong/ts-loader/pull/322) [#321] - thanks @dopare
## v0.9.3
* [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) -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) - 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) - 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
## v0.8.2
* Elided imports are now watched (#156, #169)
* Declaration files for `.d.ts` files are now emitted (thanks @rob-bateman) (#174, #175)
## v0.8.1
* Add better error messaging when a file in tsconfig.json can not be loaded (#117, #145)
* Fix incompatibility with html-webpack-plugin (#152, #154)
## v0.8.0
* Add support for emitting declaration files when `declaration: true` is set (#48, #128)
* Fix bug with specifying `target: es6` and `module: commonjs` at the same time when using
TS 1.7+ (#111, #132, #140).
* Fix bug with resolving dependencies which are linked using `npm link` (#134, #141)
## v0.7.2
* Fix regression with watching definition files (#109, #110)
## v0.7.1
* Fix regression with Windows that was introduced in v0.7.0 (#92)
## v0.7.0
* Fix bug with webpack resolution that could sometimes cause TypeScript to not find modules (#92, #102)
* Loader output is now written to stderr instead of stdout. (#95, #103)
## v0.6.1
* Improve initial build performance significantly for larger projects (#100)
* Fix issue with nightly (#96)
## v0.6.0
* Remove support for 1.5 and 1.6-beta. TypeScript 1.6 (stable) is the now the lowest version
supported.
* Fix issue when using source maps and Babel in certain situations (#81)
* Fix issue with nightly (#83)
## v0.5.6
* Add ignoreDiagnostics feature
* Fix issue with node resolution and `noEmitOnError` (#71)
## v0.5.5
* Fix issue with nightly (Microsoft/TypeScript#4738)
* Add support for the NoErrorsPlugin
## v0.5.4
* Fix issue with nightly (Microsoft/TypeScript#4497)
## v0.5.3
* Utilize TypeScript's new custom module resolution logic to integrate with webpack. This essentially
means that TypeScript will resolve files exactly the same as webpack does (supporting aliases, etc).
See the [aliasResolution test](test/aliasResolution) for an example. Only supported in TS 1.6 and
above.
* Rework error reporting to resolve certain edge cases with dependencies. In general errors should
be much more consistent now in watch mode.
* Fix issue with targeting ES6 and transpile mode (#36)
## v0.5.2
* Fix issue with TypeScript nightly and new node module resolution strategy (#34)
## v0.5.1
* Tweaked error message output to include error code (#32)
* Add helpful messages around the TypeScript dependency
* Suggest how to install TypeScript if it hasn't been installed
* Show TypeScript version when compiling
* Warn if TypeScript version is incompatible
## v0.5.0
* Add support for `transpileOnly` loader option. See README for more information.
* TypeScript is no longer a dependency of the loader and must be installed separately
* Loader options can now be set as a property in `webpack.config.js`
* TypeScript options can be set through the loader option `compilerOptions`
* Improved error reporting
* Errors from all files in the TypeScript application are now reported in watch mode instead of
from just those files that changed. This means that making a breaking change in a dependency
will now be correctly reported as an error in the dependent file.
* Errors with TypeScript options are now reported as webpack errors instead of logged to console
* Error output no longer contains the filename once from webpack and again in the error message.
Instead, the filename is only reported by webpack
* Fixed issue with latest version of webpack where filenames could be reported twice for the same
error in certain situations
* Using the `declaration` TypeScript option no longer results in errors
* Add support for the `newLine` TypeScript option
* Tests have been revamped to be full integration tests with nightly builds against the current stable
and nightly TypeScript. Many new tests have been added.
## v0.4.7
* Update TypeScript dependency to 1.5 release (1.5.3)
## v0.4.6
* Improve error reporting related to tsconfig.json
* Fix bug that reported the wrong errors
* Errors are now reported as webpack errors instead of logged to console
* Add support for latest TypeScript nightly (#24)
## v0.4.5
* Add `silent` flag (#22)
## v0.4.4
* Add support for "noLib" compiler option (#19)
* Make errors easier to parse programmatically (#20)
* Errors in declaration files are now added to the stats object instead of written to console
* Errors now include `file`, `rawMessage`, and `location` properties
* Make --watch option more robust
* Fix issue where changes to entry file were not detected
* Fix issue where changes to typing information only did not result in a rebuild (#21)
## v0.4.3
* Fix error locations to be 1-based instead of 0-based (#18)
## v0.4.2
* Rework the way dependencies are loaded (#14)
* Fix NPM dependency on TypeScript (#15, #16)
## v0.4.1
* Fix Windows issue with paths (#14)
## v0.4.0
* TypeScript 1.5 support! (#14)
* tsconfig.json support (#2, #9)
* ES6 target support
* Remove TS-related options in favor of specifying them in tsconfig.json
* Add `configFileName` option for custom tsconfig files
## v0.3.4
* Exclude TS 1.5 as a dependency since there are breaking changes
## v0.3.3
* Add support for reporting errors in declaration files (#10)
* Add support for watch mode for declaration files (#11)
* Fix issue with extra `sourceMappingURL` in output files (#12)
## v0.3.2
* Add support for manually adding files (#6)
* Add paths to source maps (#8)
## v0.3.1
* Add support for specifying a custom TypeScript compiler
## v0.3.0
* Change how modules are resolved. Imports and declaration file references are
now resolved through TypeScript instead of being resolved through webpack's
`resolve` API. This fixes a number of issues and better aligns the loader to
work as a replacement for the `tsc` command. (#3, #4, #5)
## v0.2.3
* Add noImplicitAny option (#2)
## v0.2.2
* Fix issue with source maps
## v0.2.1
* Add colors to error output
## v0.2.0
* Add new configuration options (#1)
* target, module, sourceMap, instance
* sourceMap default changed from `true` to `false`
* Workaround issue with TypeScript always emitting Windows-style new lines
* Add tests
## v0.1.0
* Initial version
ts-loader-9.4.2/CONTRIBUTING.md 0000664 0000000 0000000 00000012012 14341700417 0015646 0 ustar 00root root 0000000 0000000 # Contributor's Guide
We welcome contributions from the community and have gathered guidelines
here to help you get started.
## Discussion
While not absolutely required, it is encouraged that you first open an issue
for any bug or feature request. This allows discussion on the proper course of
action to take before coding begins.
## Building
```shell
yarn install
yarn 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, make your changes, and submit a pull request.
## Testing
This project makes use of 2 integration test packs to make sure we don't break anything. That's right, count them, 2! There is a comparison test pack which compares compilation outputs and is long established. There is also an execution test pack which executes the compiled JavaScript. This test pack is young and contains fewer tests; but it shows promise.
You can run all the tests (in both test packs) with `yarn test`.
To run comparison tests alone use `yarn run comparison-tests`.
To run execution tests alone use `yarn 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.
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)
## Debugging
### Debugging tests
If you’re using VS Code, set breakpoints anywhere in `src`. Open any file inside the comparison test or execution test you want to debug, then, in the debug pane, select “Run open comparison test” or “Run open execution test.”
If you’re not using VS Code, simply adding `--debug` to either a `yarn run comparison-tests` or `yarn run execution-tests` will pause before each test (this is best combined with `--single-test`), allowing you to attach to the node process on port 5858 with your favorite debugger.
### Debugging ts-loader installed from npm in your own Webpack project
```sh
node --inspect-brk node_modules/webpack/bin/webpack.js --config webpack.dev.js # Obviously configure this depending upon your project setup
```
Then put a breakpoint in `node_modules/ts-loader/dist/index.js`, and debug in VS Code with "Attach to Node Process". The dist is JS compiled from TS, but it’s still pretty readable.
### Debugging a local, cloned copy of ts-loader in your own Webpack project
Just like the steps above, except substituting a local copy of ts-loader for the one in node_modules:
1. In `ts-loader`, run `yarn build`
2. Still in `ts-loader`, run `npm link`
3. In your own Webpack project directory, run `npm link ts-loader`. There’s now a chain of symlinks from `node_modules/ts-loader` to your cloned copy built from source.
4. Repeat the steps above in “Debugging ts-loader installed from npm...” except now, you can take advantage of source maps, so you can set breakpoints in `ts-loader/src` instead of `ts-loader/dist`.
5. If you want to try making changes to `ts-loader`, make changes and then repeat steps 1 and 4—no need to re-run the `npm link` steps.
6. Run `npm unlink ts-loader` in your own project directory to remove the symlink when you’re done.
### Profiling Performance
To investigate slowdowns in build times, it's often helpful to profile webpack & ts-loader.
1. Start webpack with a debugger attached (see debugging steps above)
2. Identify the reproducible user scenario that is experiencing slowdowns
3. In Chrome, open `chrome://inspect` and inspect the running webpack instance
Note: Utilizing Chromium instead of Chrome sometimes yields better results. If any of the following steps fail or cause a crash, try switching from Chrome to Chromium.
4. Switch to the Profiling Tab
5. Start Recording
6. Kick off the scenario that's known to be slow
7. Stop Recording once the scenario is complete
At this point you should see a list of function calls. There are three distinct views that are useful & you can swap between them to get slightly different views of the problem.
**Chart View**
The chart view will provide a flame chart of all profiled function calls over time. This can be useful to visualize expensive functions and blocks of high CPU, but can be difficult to read when there are deep call stacks (or flames).
**Heavy View**
Heavy view shows the time that functions took to execute themselves (self time) & the functions they call (total time). When expanding individual calls, you will be able to see the functions that called this function & effectively walk up the recorded stack traces.
**Tree View**
Tree view shows the same information as heavy view, but visualizes calls in a top-town manner. This can be useful to track down a single call pattern that is expensive but is less useful when there are deep stack traces.
ts-loader-9.4.2/Dockerfile 0000664 0000000 0000000 00000003076 14341700417 0015421 0 ustar 00root root 0000000 0000000 FROM node:14
# See https://crbug.com/795759
RUN apt-get update && apt-get install -yq libgconf-2-4
# Install latest chrome dev package and fonts to support major charsets (Chinese, Japanese, Arabic, Hebrew, Thai and a few others)
# Note: this installs the necessary libs to make the bundled version of Chromium that Puppeteer
# installs, work.
RUN apt-get update && apt-get install -y wget --no-install-recommends \
&& wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - \
&& sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' \
&& apt-get update \
&& apt-get install -y google-chrome-unstable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf \
--no-install-recommends \
&& rm -rf /var/lib/apt/lists/* \
&& apt-get purge --auto-remove -y curl \
&& rm -rf /src/*.deb
WORKDIR /TypeStrong/ts-loader
COPY .git /TypeStrong/ts-loader/.git
# install packages
COPY package.json yarn.lock index.js /TypeStrong/ts-loader/
RUN yarn
# build
COPY src /TypeStrong/ts-loader/src
RUN yarn build
# test
COPY test /TypeStrong/ts-loader/test
# build and run tests with:
# docker build -t ts-loader .
# docker run -it ts-loader yarn test
# regenerate comparison-tests with:
# docker build -t ts-loader .
# docker run -v $(pwd):/TypeStrong/ts-loader -it ts-loader yarn
# docker run -v $(pwd):/TypeStrong/ts-loader -it ts-loader yarn build
# docker run -v $(pwd):/TypeStrong/ts-loader -it ts-loader yarn run comparison-tests --save-output
ts-loader-9.4.2/HISTORY.md 0000664 0000000 0000000 00000001557 14341700417 0015114 0 ustar 00root root 0000000 0000000 # History
`ts-loader` was started by [James Brantly](http://www.jbrantly.com/) back in January 2015. He created the initial codebase, wrote the comparison testpack and merrily maintained it until it reached v0.8.2.
At that point [John Reilly](https://blog.johnnyreilly.com/) started maintaining ts-loader. [On October 16th 2016 to be exact](https://twitter.com/jbrantly/status/785931975064444928). The full story of how that came to be can be read here: https://blog.johnnyreilly.com/2016/11/but-you-cant-die-i-love-you-ts-loader.html
Since that time, John (who wrote this and finds it peculiar to refer to himself in the third person) has continued maintaining ts-loader. He appreciates any and all people that contribute. Who knows, maybe one day the mantle will be passed on again and someone else will step up and take ts-loader forwards. Who knows? It could be you ;-) ts-loader-9.4.2/LICENSE 0000664 0000000 0000000 00000002076 14341700417 0014433 0 ustar 00root root 0000000 0000000 The MIT License (MIT)
Copyright (c) 2015-present TypeStrong
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
ts-loader-9.4.2/README.md 0000664 0000000 0000000 00000073705 14341700417 0014714 0 ustar 00root root 0000000 0000000 # TypeScript loader for webpack
[](https://www.npmjs.com/package/ts-loader)
[](https://github.com/TypeStrong/ts-loader/actions/workflows/push.yml)
[](https://npmjs.org/package/ts-loader)
[](https://www.npmjs.com/package/ts-loader)
[](https://github.com/prettier/prettier)
## Table of Contents
- [Getting Started](#getting-started)
* [Installation](#installation)
* [Running](#running)
* [Examples](#examples)
* [Faster Builds](#faster-builds)
* [Yarn Plug’n’Play](#yarn-plugnplay)
* [Babel](#babel)
* [Compatibility](#compatibility)
* [Configuration](#configuration)
+ [`devtool` / sourcemaps](#devtool--sourcemaps)
* [Code Splitting and Loading Other Resources](#code-splitting-and-loading-other-resources)
* [Declarations (.d.ts)](#declaration-files-dts)
* [Failing the build on TypeScript compilation error](#failing-the-build-on-typescript-compilation-error)
* [`baseUrl` / `paths` module resolution](#baseurl--paths-module-resolution)
* [Options](#options)
* [Loader Options](#loader-options)
+ [transpileOnly](#transpileonly)
+ [happyPackMode](#happypackmode)
+ [resolveModuleName and resolveTypeReferenceDirective](#resolvemodulename-and-resolvetypereferencedirective)
+ [getCustomTransformers](#getcustomtransformers)
+ [logInfoToStdOut](#loginfotostdout)
+ [logLevel](#loglevel)
+ [silent](#silent)
+ [ignoreDiagnostics](#ignorediagnostics)
+ [reportFiles](#reportfiles)
+ [compiler](#compiler)
+ [configFile](#configfile)
+ [colors](#colors)
+ [errorFormatter](#errorformatter)
+ [compilerOptions](#compileroptions)
+ [instance](#instance)
+ [appendTsSuffixTo](#appendtssuffixto)
+ [appendTsxSuffixTo](#appendtsxsuffixto)
+ [onlyCompileBundledFiles](#onlycompilebundledfiles)
+ [useCaseSensitiveFileNames](#useCaseSensitiveFileNames)
+ [allowTsInNodeModules](#allowtsinnodemodules)
+ [context](#context)
+ [experimentalFileCaching](#experimentalfilecaching)
+ [projectReferences](#projectreferences)
* [Usage with webpack watch](#usage-with-webpack-watch)
* [Hot Module replacement](#hot-module-replacement)
- [Contributing](#contributing)
- [License](#license)
## Getting Started
### Installation
```
yarn add ts-loader --dev
```
or
```
npm install ts-loader --save-dev
```
You will also need to install TypeScript if you have not already.
```
yarn add typescript --dev
```
or
```
npm install typescript --save-dev
```
### Running
Use webpack like normal, including `webpack --watch` and `webpack-dev-server`, or through another
build system using the [Node.js API](https://webpack.js.org/api/node/).
### Examples
We have a number of example setups to accommodate different workflows. Our examples can be found [here](examples/).
We probably have more examples than we need. That said, here's a good way to get started:
- I want the simplest setup going. Use "[vanilla](examples/vanilla)" `ts-loader`
- I want the fastest compilation that's available. Use [fork-ts-checker-webpack-plugin](https://github.com/TypeStrong/fork-ts-checker-webpack-plugin). It performs type checking in a separate process with `ts-loader` just handling transpilation.
### Faster Builds
As your project becomes bigger, compilation time increases linearly. It's because typescript's semantic checker has to inspect all files on every rebuild.
The simple solution is to disable it by using the `transpileOnly: true` option, but doing so leaves you without type checking and *will not output declaration files*.
You probably don't want to give up type checking; that's rather the point of TypeScript. So what you can do is use the [fork-ts-checker-webpack-plugin](https://github.com/TypeStrong/fork-ts-checker-webpack-plugin).
It runs the type checker on a separate process, so your build remains fast thanks to `transpileOnly: true` but you still have the type checking.
If you'd like to see a simple setup take a look at [our example](examples/fork-ts-checker-webpack-plugin/).
### Yarn Plug’n’Play
`ts-loader` supports [Yarn Plug’n’Play](https://yarnpkg.com/en/docs/pnp). The recommended way to integrate is using the [pnp-webpack-plugin](https://github.com/arcanis/pnp-webpack-plugin#ts-loader-integration).
### Babel
`ts-loader` works very well in combination with [babel](https://babeljs.io/) and [babel-loader](https://github.com/babel/babel-loader). There is an [example](https://github.com/Microsoft/TypeScriptSamples/tree/master/react-flux-babel-karma) of this in the official [TypeScript Samples](https://github.com/Microsoft/TypeScriptSamples).
### Compatibility
* TypeScript: 3.6.3+
* webpack: 5.x+ (please use `ts-loader` 8.x if you need webpack 4 support)
* node: 12.x+
A full test suite runs each night (and on each pull request). It runs both on Linux and Windows, testing `ts-loader` against major releases of TypeScript. The test suite also runs against TypeScript@next (because we want to use it as much as you do).
If you become aware of issues not caught by the test suite then please let us know. Better yet, write a test and submit it in a PR!
### Configuration
1. Create or update `webpack.config.js` like so:
```javascript
module.exports = {
mode: "development",
devtool: "inline-source-map",
entry: "./app.ts",
output: {
filename: "bundle.js"
},
resolve: {
// Add `.ts` and `.tsx` as a resolvable extension.
extensions: [".ts", ".tsx", ".js"],
// Add support for TypeScripts fully qualified ESM imports.
extensionAlias: {
".js": [".js", ".ts"],
".cjs": [".cjs", ".cts"],
".mjs": [".mjs", ".mts"]
}
},
module: {
rules: [
// all files with a `.ts`, `.cts`, `.mts` or `.tsx` extension will be handled by `ts-loader`
{ test: /\.([cm]?ts|tsx)$/, loader: "ts-loader" }
]
}
};
```
2. Add a [`tsconfig.json`](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html) file. (The one below is super simple; but you can tweak this to your hearts desire)
```json
{
"compilerOptions": {
"sourceMap": true
}
}
```
The [tsconfig.json](http://www.typescriptlang.org/docs/handbook/tsconfig-json.html) file controls
TypeScript-related options so that your IDE, the `tsc` command, and this loader all share the
same options.
#### `devtool` / sourcemaps
If you want to be able to debug your original source then you can thanks to the magic of sourcemaps. There are 2 steps to getting this set up with `ts-loader` and webpack.
First, for `ts-loader` to produce **sourcemaps**, you will need to set the [tsconfig.json](http://www.typescriptlang.org/docs/handbook/tsconfig-json.html) option as `"sourceMap": true`.
Second, you need to set the `devtool` option in your `webpack.config.js` to support the type of sourcemaps you want. To make your choice have a read of the [`devtool` webpack docs](https://webpack.js.org/configuration/devtool/). You may be somewhat daunted by the choice available. You may also want to vary the sourcemap strategy depending on your build environment. Here are some example strategies for different environments:
* `devtool: 'inline-source-map'` - Solid sourcemap support; the best "all-rounder". Works well with karma-webpack (not all strategies do)
* `devtool: 'eval-cheap-module-source-map'` - Best support for sourcemaps whilst debugging.
* `devtool: 'source-map'` - Approach that plays well with UglifyJsPlugin; typically you might use this in Production
### Code Splitting and Loading Other Resources
Loading css and other resources is possible but you will need to make sure that
you have defined the `require` function in a [declaration file](https://www.typescriptlang.org/docs/handbook/writing-declaration-files.html).
```typescript
declare var require: {
(path: string): T;
(paths: string[], callback: (...modules: any[]) => void): void;
ensure: (
paths: string[],
callback: (require: (path: string) => T) => void
) => void;
};
```
Then you can simply require assets or chunks per the [webpack documentation](https://webpack.js.org/guides/code-splitting/).
```javascript
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](https://webpack.js.org/guides/code-splitting/). See [this example](test/comparison-tests/codeSplitting) and [this example](test/comparison-tests/es6codeSplitting) for more details.
[TypeScript 2.4 provides support for ECMAScript's new `import()` calls. These calls import a module and return a promise to that module.](https://blogs.msdn.microsoft.com/typescript/2017/06/12/announcing-typescript-2-4-rc/) This is also supported in webpack - details on usage can be found [here](https://webpack.js.org/guides/code-splitting-async/#dynamic-import-import-). Happy code splitting!
### Declaration Files (.d.ts)
To output declaration files (.d.ts), you can set "declaration": true in your tsconfig and set "transpileOnly" to false.
If you use ts-loader with "transpileOnly": true along with [fork-ts-checker-webpack-plugin](https://github.com/TypeStrong/fork-ts-checker-webpack-plugin), you will need to configure fork-ts-checker-webpack-plugin to output definition files, you can learn more on the plugin's documentation page: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin#typescript-options
To output a built .d.ts file, you can use the [DeclarationBundlerPlugin](https://www.npmjs.com/package/declaration-bundler-webpack-plugin) in your webpack config.
### Failing the build on TypeScript compilation error
The build **should** fail on TypeScript compilation errors as of webpack 2. If for some reason it does not, you can use the [webpack-fail-plugin](https://www.npmjs.com/package/webpack-fail-plugin).
For more background have a read of [this issue](https://github.com/TypeStrong/ts-loader/issues/108).
### `baseUrl` / `paths` module resolution
If you want to resolve modules according to `baseUrl` and `paths` in your `tsconfig.json` then you can use the [tsconfig-paths-webpack-plugin](https://www.npmjs.com/package/tsconfig-paths-webpack-plugin) package. For details about this functionality, see the [module resolution documentation](https://www.typescriptlang.org/docs/handbook/module-resolution.html#base-url).
This feature requires webpack 2.1+ and TypeScript 2.0+. Use the config below or check the [package](https://github.com/dividab/tsconfig-paths-webpack-plugin/blob/master/README.md) for more information on usage.
```javascript
const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');
module.exports = {
...
resolve: {
plugins: [new TsconfigPathsPlugin({ configFile: "./path/to/tsconfig.json" })]
}
...
}
```
### Options
There are two types of options: TypeScript options (aka "compiler options") and loader options. TypeScript options should be set using a tsconfig.json file. Loader options can be specified through the `options` property in the webpack configuration:
```javascript
module.exports = {
...
module: {
rules: [
{
test: /\.tsx?$/,
use: [
{
loader: 'ts-loader',
options: {
transpileOnly: true
}
}
]
}
]
}
}
```
### Loader Options
#### transpileOnly
| Type | Default Value |
|------|--------------|
| `boolean` | `false`|
If you want to speed up compilation significantly you can set this flag.
However, many of the benefits you get from static type checking between different dependencies in your application will be lost. `transpileOnly` will *not* speed up compilation of project references.
It's advisable to use `transpileOnly` alongside the [fork-ts-checker-webpack-plugin](https://github.com/TypeStrong/fork-ts-checker-webpack-plugin) to get full type checking again. To see what this looks like in practice then either take a look at [our example](examples/fork-ts-checker-webpack-plugin).
> Tip: When you add the [fork-ts-checker-webpack-plugin](https://github.com/TypeStrong/fork-ts-checker-webpack-plugin) to your webpack config, the `transpileOnly` will default to `true`, so you can skip that option.
If you enable this option, webpack 4 will give you "export not found" warnings any time you re-export a type:
```
WARNING in ./src/bar.ts
1:0-34 "export 'IFoo' was not found in './foo'
@ ./src/bar.ts
@ ./src/index.ts
```
The reason this happens is that when typescript doesn't do a full type check, it does not have enough information to determine whether an imported name is a type or not, so when the name is then exported, typescript has no choice but to emit the export. Fortunately, the extraneous export should not be harmful, so you can just suppress these warnings:
```javascript
module.exports = {
...
stats: {
warningsFilter: /export .* was not found in/
}
}
```
#### happyPackMode
| Type | Default Value |
|------|--------------|
| `boolean` | `false`|
If you're using [HappyPack](https://github.com/amireh/happypack) or [thread-loader](https://github.com/webpack-contrib/thread-loader) to parallelise your builds then you'll need to set this to `true`. This implicitly sets `*transpileOnly*` to `true` and **WARNING!** stops registering **_all_** errors to webpack.
It's advisable to use this with the [fork-ts-checker-webpack-plugin](https://github.com/TypeStrong/fork-ts-checker-webpack-plugin) to get full type checking again. **_IMPORTANT_**: If you are using fork-ts-checker-webpack-plugin alongside HappyPack or thread-loader then ensure you set the `syntactic` diagnostic option like so:
```javascript
new ForkTsCheckerWebpackPlugin({
typescript: {
diagnosticOptions: {
semantic: true,
syntactic: true,
},
},
})
```
This will ensure that the plugin checks for both syntactic errors (eg `const array = [{} {}];`) and semantic errors (eg `const x: number = '1';`). By default the plugin only checks for semantic errors (as when used with `ts-loader` in `transpileOnly` mode, `ts-loader` will still report syntactic errors).
Also, if you are using `thread-loader` in watch mode, remember to set `poolTimeout: Infinity` so workers don't die.
#### resolveModuleName and resolveTypeReferenceDirective
These options should be functions which will be used to resolve the import statements and the `` directives instead of the default TypeScript implementation. It's not intended that these will typically be used by a user of `ts-loader` - they exist to facilitate functionality such as [Yarn Plug’n’Play](https://yarnpkg.com/en/docs/pnp).
#### getCustomTransformers
| Type |
|------|
| ` (program: Program, getProgram: () => Program) => { before?: TransformerFactory[]; after?: TransformerFactory[]; afterDeclarations?: TransformerFactory[]; } ` |
Provide custom transformers - only compatible with TypeScript 2.3+ (and 2.4 if using `transpileOnly` mode). For example usage take a look at [typescript-plugin-styled-components](https://github.com/Igorbek/typescript-plugin-styled-components) or our [test](test/comparison-tests/customTransformer).
You can also pass a path string to locate a js module file which exports the function described above, this useful especially in `happyPackMode`. (Because forked processes cannot serialize functions see more at [related issue](https://github.com/Igorbek/typescript-plugin-styled-components/issues/6#issue-303387183))
#### logInfoToStdOut
| Type | Default Value |
|------|--------------|
| `boolean` | `false`|
This is important if you read from stdout or stderr and for proper error handling.
The default value ensures that you can read from stdout e.g. via pipes or you use webpack -j to generate json output.
#### logLevel
| Type | Default Value |
|------|--------------|
| `string` | `warn` |
Can be `info`, `warn` or `error` which limits the log output to the specified log level.
Beware of the fact that errors are written to stderr and everything else is written to stderr (or stdout if logInfoToStdOut is true).
#### silent
| Type | Default Value |
|------|--------------|
| `boolean` | `false`|
If `true`, no console.log messages will be emitted. Note that most error
messages are emitted via webpack which is not affected by this flag.
#### ignoreDiagnostics
| Type | Default Value |
|------|--------------|
| `number[]` | `[]`|
You can squelch certain TypeScript errors by specifying an array of diagnostic
codes to ignore.
#### reportFiles
| Type | Default Value |
|------|--------------|
| `string[]` | `[]`|
Only report errors on files matching these glob patterns.
```javascript
// in webpack.config.js
{
test: /\.ts$/,
loader: 'ts-loader',
options: { reportFiles: ['src/**/*.{ts,tsx}', '!src/skip.ts'] }
}
```
This can be useful when certain types definitions have errors that are not fatal to your application.
#### compiler
| Type | Default Value |
|------|--------------|
| `string` | `'typescript'`|
Allows use of TypeScript compilers other than the official one. Should be
set to the NPM name of the compiler, eg [`ntypescript`](https://github.com/basarat/ntypescript).
#### configFile
| Type | Default Value |
|------|--------------|
| `string` | `'tsconfig.json'`|
Allows you to specify where to find the TypeScript configuration file.
You may provide
* just a file name. The loader then will search for the config file of each entry point in the respective entry point's containing folder. If a config file cannot be found there, it will travel up the parent directory chain and look for the config file in those folders.
* a relative path to the configuration file. It will be resolved relative to the respective `.ts` entry file.
* an absolute path to the configuration file.
Please note, that if the configuration file is outside of your project directory, you might need to set the `context` option to avoid TypeScript issues (like TS18003).
In this case the `configFile` should point to the `tsconfig.json` and `context` to the project root.
#### colors
| Type | Default Value |
|------|--------------|
| `boolean` | `true`|
If `false`, disables built-in colors in logger messages.
#### errorFormatter
| Type | Default Value |
|------|--------------|
| `(message: ErrorInfo, colors: boolean) => string` | `undefined`|
By default `ts-loader` formats TypeScript compiler output for an error or a warning in the style:
```
[tsl] ERROR in myFile.ts(3,14)
TS4711: you did something very wrong
```
If that format is not to your taste you can supply your own formatter using the `errorFormatter` option. Below is a template for a custom error formatter. Please note that the `colors` parameter is an instance of [`chalk`](https://github.com/chalk/chalk) which you can use to color your output. (This instance will respect the `colors` option.)
```javascript
function customErrorFormatter(error, colors) {
const messageColor =
error.severity === "warning" ? colors.bold.yellow : colors.bold.red;
return (
"Does not compute.... " +
messageColor(Object.keys(error).map(key => `${key}: ${error[key]}`))
);
}
```
If the above formatter received an error like this:
```json
{
"code":2307,
"severity": "error",
"content": "Cannot find module 'components/myComponent2'.",
"file":"/.test/errorFormatter/app.ts",
"line":2,
"character":31
}
```
It would produce an error message that said:
```
Does not compute.... code: 2307,severity: error,content: Cannot find module 'components/myComponent2'.,file: /.test/errorFormatter/app.ts,line: 2,character: 31
```
And the bit after "Does not compute.... " would be red.
#### compilerOptions
| Type | Default Value |
|------|--------------|
| `object` | `{}`|
Allows overriding TypeScript options. Should be specified in the same format
as you would do for the `compilerOptions` property in tsconfig.json.
#### instance
| Type | Default Value |
|------|--------------|
| `string` | `TODO`|
Advanced option to force files to go through different instances of the
TypeScript compiler. Can be used to force segregation between different parts
of your code.
#### appendTsSuffixTo
| Type | Default Value |
|------|--------------|
| `(RegExp \| string)[]` | `[]`|
#### appendTsxSuffixTo
| Type | Default Value |
|------|--------------|
| `(RegExp \| string)[]` | `[]`|
A list of regular expressions to be matched against filename. If filename matches one of the regular expressions, a `.ts` or `.tsx` suffix will be appended to that filename.
If you're using [HappyPack](https://github.com/amireh/happypack) or [thread-loader](https://github.com/webpack-contrib/thread-loader) with `ts-loader`, you need use the `string` type for the regular expressions, not `RegExp` object.
```js
// change this:
{ appendTsSuffixTo: [/\.vue$/] }
// to:
{ appendTsSuffixTo: ['\\.vue$'] }
```
This is useful for `*.vue` [file format](https://vuejs.org/v2/guide/single-file-components.html) for now. (Probably will benefit from the new single file format in the future.)
Example:
webpack.config.js:
```javascript
module.exports = {
entry: "./index.vue",
output: { filename: "bundle.js" },
resolve: {
extensions: [".ts", ".vue"]
},
module: {
rules: [
{ test: /\.vue$/, loader: "vue-loader" },
{
test: /\.ts$/,
loader: "ts-loader",
options: { appendTsSuffixTo: [/\.vue$/] }
}
]
}
};
```
index.vue
```vue
hello {{msg}}
```
We can handle `.tsx` by quite similar way:
webpack.config.js:
```javascript
module.exports = {
entry: './index.vue',
output: { filename: 'bundle.js' },
resolve: {
extensions: ['.ts', '.tsx', '.vue', '.vuex']
},
module: {
rules: [
{ test: /\.vue$/, loader: 'vue-loader',
options: {
loaders: {
ts: 'ts-loader',
tsx: 'babel-loader!ts-loader',
}
}
},
{ test: /\.ts$/, loader: 'ts-loader', options: { appendTsSuffixTo: [/TS\.vue$/] } }
{ test: /\.tsx$/, loader: 'babel-loader!ts-loader', options: { appendTsxSuffixTo: [/TSX\.vue$/] } }
]
}
}
```
tsconfig.json (set `jsx` option to `preserve` to let babel handle jsx)
```json
{
"compilerOptions": {
"jsx": "preserve"
}
}
```
index.vue
```vue
```
Or if you want to use only tsx, just use the `appendTsxSuffixTo` option only:
```javascript
{ test: /\.ts$/, loader: 'ts-loader' }
{ test: /\.tsx$/, loader: 'babel-loader!ts-loader', options: { appendTsxSuffixTo: [/\.vue$/] } }
```
#### onlyCompileBundledFiles
| Type | Default Value |
|------|--------------|
| `boolean` | `false`|
The default behavior of `ts-loader` is to act as a drop-in replacement for the `tsc` command,
so it respects the `include`, `files`, and `exclude` options in your `tsconfig.json`, loading
any files specified by those options. The `onlyCompileBundledFiles` option modifies this behavior,
loading only those files that are actually bundled by webpack, as well as any `.d.ts` files included
by the `tsconfig.json` settings. `.d.ts` files are still included because they may be needed for
compilation without being explicitly imported, and therefore not picked up by webpack.
#### useCaseSensitiveFileNames
| Type | Default Value |
|------|--------------|
| `boolean` | determined by typescript based on platform |
The default behavior of `ts-loader` is to act as a drop-in replacement for the `tsc` command,
so it respects the `useCaseSensitiveFileNames` set internally by typescript. The `useCaseSensitiveFileNames` option modifies this behavior,
by changing the way in which ts-loader resolves file paths to compile. Setting this to true can have some performance benefits due to simplifying the file resolution codepath.
#### allowTsInNodeModules
| Type | Default Value |
|------|--------------|
| `boolean` | `false`|
By default, `ts-loader` will not compile `.ts` files in `node_modules`.
You should not need to recompile `.ts` files there, but if you really want to, use this option.
Note that this option acts as a *whitelist* - any modules you desire to import must be included in
the `"files"` or `"include"` block of your project's `tsconfig.json`.
See: [https://github.com/Microsoft/TypeScript/issues/12358](https://github.com/Microsoft/TypeScript/issues/12358)
```javascript
// in webpack.config.js
{
test: /\.ts$/,
loader: 'ts-loader',
options: { allowTsInNodeModules: true }
}
```
And in your `tsconfig.json`:
```json
{
"include": [
"node_modules/whitelisted_module.ts"
],
"files": [
"node_modules/my_module/whitelisted_file.ts"
]
}
```
#### context
| Type | Default Value |
|------|--------------|
| `string` | `undefined`|
If set, will parse the TypeScript configuration file with given **absolute path** as base path.
Per default the directory of the configuration file is used as base path. Relative paths in the configuration
file are resolved with respect to the base path when parsed. Option `context` allows to set option
`configFile` to a path other than the project root (e.g. a NPM package), while the base path for `ts-loader`
can remain the project root.
Keep in mind that **not** having a `tsconfig.json` in your project root can cause different behaviour between `ts-loader` and `tsc`.
When using editors like `VS Code` it is advised to add a `tsconfig.json` file to the root of the project and extend the config file
referenced in option `configFile`. For more information please [read the PR](https://github.com/TypeStrong/ts-loader/pull/681) that
is the base and [read the PR](https://github.com/TypeStrong/ts-loader/pull/688) that contributed this option.
webpack:
```javascript
{
loader: require.resolve('ts-loader'),
options: {
context: __dirname,
configFile: require.resolve('ts-config-react-app')
}
}
```
Extending `tsconfig.json`:
```json
{ "extends": "./node_modules/ts-config-react-app/index" }
```
Note that changes in the extending file while not be respected by `ts-loader`. Its purpose is to satisfy the code editor.
#### experimentalFileCaching
| Type | Default Value |
|------|--------------|
| `boolean` | `true`|
By default whenever the TypeScript compiler needs to check that a file/directory exists or resolve symlinks it makes syscalls. It does not cache the result of these operations and this may result in many syscalls with the same arguments ([see comment](https://github.com/TypeStrong/ts-loader/issues/825#issue-354725524) with example).
In some cases it may produce performance degradation.
This flag enables caching for some FS-functions like `fileExists`, `realpath` and `directoryExists` for TypeScript compiler. Note that caches are cleared between compilations.
#### projectReferences
| Type | Default Value |
|------|--------------|
| `boolean` | `false`|
ts-loader has opt-in support for [project references](https://www.typescriptlang.org/docs/handbook/project-references.html). With this configuration option enabled, `ts-loader` will incrementally rebuild upstream projects the same way `tsc --build` does. Otherwise, source files in referenced projects will be treated as if they’re part of the root project.
In order to make use of this option your project needs to be correctly configured to build the project references and then to use them as part of the build. See the [Project References Guide](REFERENCES.md) and the example code in the examples which can be found [here](examples/project-references-example/).
### Usage with webpack watch
Because TS will generate .js and .d.ts files, you should ignore these files, otherwise watchers may go into an infinite watch loop. For example, when using webpack, you may wish to add this to your webpack.conf.js file:
```javascript
// for webpack 4
plugins: [
new webpack.WatchIgnorePlugin([
/\.js$/,
/\.d\.[cm]?ts$/
])
],
// for webpack 5
plugins: [
new webpack.WatchIgnorePlugin({
paths:[
/\.js$/,
/\.d\.[cm]ts$/
]})
],
```
It's worth noting that use of the `LoaderOptionsPlugin` is [only supposed to be a stopgap measure](https://webpack.js.org/plugins/loader-options-plugin/). You may want to look at removing it entirely.
### Hot Module replacement
We do not support HMR as we did not yet work out a reliable way how to set it up.
If you want to give `webpack-dev-server` HMR a try, follow the official [webpack HMR guide](https://webpack.js.org/guides/hot-module-replacement/), then tweak a few config options for `ts-loader`:
1. Set `transpileOnly` to `true` (see [transpileOnly](#transpileonly) for config details and recommendations above).
2. Inside your HMR acceptance callback function, maybe re-require the module that was replaced.
## Contributing
This is your TypeScript loader! We want you to help make it even better. Please feel free to contribute; see the [contributor's guide](CONTRIBUTING.md) to get started.
## History
`ts-loader` was started by [James Brantly](https://github.com/jbrantly), since 2016 [John Reilly](https://github.com/johnnyreilly) has been taking good care of it. If you're interested, you can [read more about how that came to pass](https://blog.johnnyreilly.com/2016/11/01/but-you-cant-die-i-love-you-ts-loader).
## License
MIT License
ts-loader-9.4.2/REFERENCES.md 0000664 0000000 0000000 00000051774 14341700417 0015402 0 ustar 00root root 0000000 0000000
# Using TypeScript Project References with ts-loader and webpack
Project References were added to TypeScript in 3.0. The benefits of using project references include:
* Better code organisation
* Logical separation between components
* Faster build times
If you are using TypeScript in your web project you can also use project references to improve your code and build workflow. This article describes some of the ways to set up your project to use references. I am using ts-loader to transpile the TypeScript code to JavaScript and webpack to bundle code.
An example repo using the configuration above is available at the link below:
[https://github.com/appzuka/project-references-example](https://github.com/appzuka/project-references-example)
There are 2 stages to using project references in your project:
1. Configure and build the project references
1. Setup your codebase to consume the compiled projects
To gain an understanding of how project references work, for the first part of this guide we will use tsc to build the project references. Later on, we will configure ts-loader to do this automatically.
### Configure and build the project references
This stage just involves following the directions from the TypeScript documentation:
[https://www.typescriptlang.org/docs/handbook/project-references.html](https://www.typescriptlang.org/docs/handbook/project-references.html)
There are a few points to note:
1. Referenced projects must have the new composite setting enabled.
1. Each referenced project has its own tsconfig.json
1. There will be a root level tsconfig.json which includes the lower level projects as references. Building this will build all subprojects.
1. You should be using configuration file inheritance ({ “extends”: …}) to avoid duplication in your config.
1. You need to use tsc --build to compile the project.
1. When you compile the project tsc --build will create a file called tsconfig.tsbuildinfo that contains the signatures and timestamps of all files required to build the project. On subsequent builds TypeScript will use that information to detect the least costly way to type-check and emit changes to your project.
1. There is no need to use the incremental compiler option. tsc --build will generate and use tsconfig.tsbuildinfo anyway.
1. If you delete your compiled code and re-run tsc --build the code will **not** be rebuilt unless you also delete the tsconfig.tsbuildinfo file. Use the tsc --build --clean command to do this for you.
1. If you set the declaration and declarationMap settings in tsconfig.json the outDir folder will contain .d.ts and .d.ts.map files alongside the transpiled JavaScript. When you consume the compiled project you should consume the outDir folder, not the src. Even though your root project is in TypeScript it can use full syntax checking without the subproject’s TypeScript source because the outDir folder contains the definitions in the .d.ts file. Vscode (and many other code editors and IDEs) will be able to find the definitions and perform syntax checking in the editor just as if you were not using project references and importing the TypeScript source directly.
### Project Structure
The TypeScript implementation of project references allows you to structure the project in almost any way you wish. Just configure the input and output folders in tsconfig.json to your needs and TypeScript will build it for you.
For a web project you might like a structure similar to the one below. You could put all your project references in a packages folder with the top-level project code in src:
```
tsconfig.json
tsconfig-base.json
src
- (source code for the main project)
dist
- main.js (final bundle produced by webpack)
packages
- reference1
- tsconfig.json (inherits from tsconfig-base.json)
- src
- lib
- reference2
- tsconfig.json (inherits from tsconfig-base.json)
- src
- lib
```
Each project reference has its own tsconfig.json with the source code for each package in a src subfolder. When the project is built the compiled JavaScript for each project will be in its lib subfolder.
The source code for your main project is in a top-level src folder and the final bundle will be in a top-level dist folder. The top-level src folder is not a referenced project — it is normal TypeScript source that webpack will bundle. It imports from the lib folders of the referenced projects built by tsc.
This structure works well because:
* Having packages grouped together under a packages folder organises your codebase nicely.
* Other tools such as yarn workspaces and lerna use and understand this organisation.
* Each package is fully self-contained in its own folder. It contains the source, compiled code, tsconfig.json and (optionally) its own package.json which describes how the package is used.
* You can drop the package into another project, import it with a simple statement and everything will be linked up.
This is just one way to structure your project. Some other options include:
* Not putting the projects references in a packages folder. They could all be at the top level, or a different folder, or nested folders.
* The output folder of each project does not have to be in a lib folder of that project. You could have a top-level lib folder which contains the output of all projects.
Almost any structure is compatible with project references. You have freedom to specify the paths of the referenced projects and their outputs in the tsconfig.json files. You will import the compiled JavaScript files into the main project and some structures make this easier than others, but you have the freedom to choose what works for you.
### Test Build your Projects
You should now check that the building of the projects is successful and produces the code you expect.
In each project reference folder execute tsc --build, check there are no errors and the output is as you expect. Use tsc --build --clean to remove the output and repeat. You can use tsc --build --verbose to see what tsc is doing.
If you have a top-level tsconfig.json similar to:
```
{
"files": ["src/index.ts"],
"references": [
{ "path": "./reference1" },
{ "path": "./reference2" }
]
}
```
Then executing tsc --build in the top-level will compile all of your subprojects with one command. The build process is smart and can manage dependencies between subprojects.
In the final step of this guide we will get ts-loader to do the build automatically when called from webpack, but for now, just make sure that the build process works when using tsc --build manually.
### Setup your codebase to consume the project
Now your subprojects are built you can use them in your root project. Let’s say your reference1 project exports a number:
```
// packages/reference1/src/index.ts
export const Meaning = 42;
```
After building the reference with tsc --build the compiled JavaScript will be found in packages/reference1/lib/index.js. In your root project you need to import this. There are several ways you can do this. Let’s start with a naive approach that will work but has severe downsides:
```
// src/index.ts
// Don't do this!
import { Meaning } from '../packages/reference1/lib';
```
This will work because TypeScript and webpack will both find the file. The downsides are:
* The organisation of your root project and components are now intertwined. If you change the internal structure of your subproject you will need to update every import statement in the entire project.
* The import location will depend on the location on the source file. For example, if you want to do the same import from a subfolder in your root project you will need to replace ../packages/reference1/lib with ../../packages/reference1/lib. If you re-organise your project structure you will need to fix every import.
The solution to this is module resolution — how TypeScript and webpack resolve the targets of import statements. You can read about this at the links below:
* [https://www.typescriptlang.org/docs/handbook/module-resolution.html](https://www.typescriptlang.org/docs/handbook/module-resolution.html)
* [https://webpack.js.org/concepts/module-resolution](https://webpack.js.org/concepts/module-resolution)
Module resolution is nothing new and it is not part of project references, but understanding it will be a huge help getting everything working. Some points to note:
* TypeScript and webpack can use different methods to resolve modules. It will help if you can set them up so they are using the same method. (See the example below using alias in webpack and/or tsconfig-paths-webpack-plugin.)
* Resolution works differently for relative (./reference1) and absolute (reference1) imports.
* TypeScript has 2 strategies for module resolution: classic and node. You probably want to use node.
* You can use a webpack plugin tsconfig-paths-webpack-plugin so that you just need to define paths in your tsconfig.json and then don’t need to repeat these in your webpack config.
Using the example above, we would like to just import from packages/reference and have TypeScript and webpack both know that this refers to the actual location.
```
// src/index.ts
// Better!
import { Meaning } from 'packages/reference1/lib';
```
We can achieve this using the paths configuration in tsconfig.json (or better, in tsconfig-base.json so the settings are made once and inherited by all projects):
```
{
"compilerOptions": {
"baseUrl": ".", // This must be specified if "paths" is.
"paths": {
"packages/*": ["packages/*"]
}
}
}
```
Now TypeScript understands that when it sees packages/reference1 in an import statement, it should look in ./packages/reference1. The path is relative to the root tsconfig.json so it does not matter where the source file which imports this is located.
Unless you are using tsconfig-paths-webpack-plugin you may need to include a corresponding resolve-alias setting in your webpack.config.js:
```
const path = require('path');
module.exports = {
modules: [
"node_modules",
path.resolve(__dirname)
],
resolve: {
alias: {
packages: path.resolve(__dirname, 'packages/'),
}
}
};
```
(In this case the path.resolve(__dirname) in the modules section accomplishes the same thing, but depending on your project structure you may need an alias.)
If you are getting module not found errors when you build, knowing whether these are coming from TypeScript or webpack will help you to resolve the issue.
Errors which come from TypeScript when you build the project look similar to the following:
```
ERROR in ...project-references-demo/src/index.tsx
./src/index.tsx
[tsl] ERROR in ...project-references-demo/src/index.tsx(1,27)
TS2307: Cannot find module 'mypackages/zoo' or its corresponding type declarations.
```
Note the [tsl] in the message and also the TypeScript error code TS2307. This indicates that the error was passed to webpack by ts-loader when it tried to transpile the file. You can also check whether errors are coming from TypeScript by building your project manually with tsc and checking whether it reports errors.
Errors from webpack look similar to the following:
```
ERROR in ./src/index.tsx
Module not found: Error: Can't resolve 'mypackages/zoo' in '...project-references-demo/src'
@ ./src/index.tsx 6:12-37
```
If you just get these errors it indicates that tsconfig.json is correctly configured and TypeScript is able to resolve your modules, but webpack is not. Look into the resolve section of webpack.config.js and check whether you need to add an alias.
You can use module resolution to make your project work with project references even if your structure is very different from that outlined here. As long as webpack and TypeScript can find the built code it will work.
### Can you import the TypeScript Source instead of the JavaScript?
You can import the TypeScript source from your projects, but you probably should not. If you do set up your project to import the TypeScript, webpack will bundle your project just fine, but then you are not using project references. You have succeeded in organising your codebase but you are not getting the advantage of reducing build time by using the compiled files in lib. In fact, you are slowing down your build by requiring tsc or ts-loader to build the reference and then not using it.
If your project is large you could see a significant benefit from pre-building large sections of code. If your project is not so large you may prefer to just structure your codebase and skip project references.
### Using ts-loader to build project references
Up to this point, we ran tsc --build on its own and then used webpack and ts-loader to build the whole project, importing the references. You can configure ts-loader to build the references for you, which simplifies the build process.
The top-level project in src is TypeScript code, so you will already be using ts-loader to load the TypeScript source into webpack. Just add projectReferences: true to the ts-loader configuration and you no longer need to run tsc in a separate process:
```
// webpack.config.js
"module": {
"rules": [
{
"test": /\.tsx?$/,
"exclude": /node_modules/,
"use": {
"loader": "ts-loader",
"options": {
"projectReferences": true
}
}
}
]
}
```
When webpack uses ts-loader to process a TypeScript file ts-loader will now check whether any of your project references need rebuilding and rebuild them before webpack proceeds if necessary. This includes when webpack is in watch mode as used by webpack-dev-server.
Setting projectReferences: true in ts-loader alone will not magically convert your code to use project references. All it does is to run tsc --build as part of the build process. You need to configure project references and structure your project to use them as described here.
If you have come this far congratulations — you are now using TypeScript project references in your web project. You can stop here, but in the next section of this guide there are some tips to clean up the project further and create a library of reusable, version-controlled components.
### Using package.json
We can clean this up further by including a package.json in the project reference subfolder. If this contains the following:
```
//packages/reference1/package.json
{
"name": "reference1",
"version": "1.0.0",
"description": "Project Reference1",
"main": "lib/index.js",
"directories": {
"lib": "lib"
},
"license": "ISC"
}
```
then you can just import as follows:
```
// src/index.ts
import { Meaning } from 'packages/reference1';
```
The module setting in package.json tells the bundler to import from lib/index.js when it sees the import statement above.
### Using node_modules
In the above approach we need to add paths to tsconfig.json so that the module resolution knows where to find our package. But the module resolution system automatically looks in node_modules, so if we link our reference in node_modules we won’t need the paths and aliases:
```
ln -s ../packages/reference1 node_modules/reference1
node_modules/reference1 -> packages/reference1
```
It probably makes sense to use npm scopes:
```
ln -f ../../packages/reference1 node_modules/@myscope/reference1
node_modules/@myscope/reference1 -> packages/reference1
````
then you can consume the code with:
```
// src/index.ts
import { Meaning } from '@myscope/reference1';
```
So you benefit from not having to configure paths and aliases, but you need to create the links in node_modules after cloning the project, unless you use Yarn workspaces.
### Using Yarn Workspaces
If you use yarn workspaces the node_modules links will automatically be created for you when you execute yarn install. Simply include the following in your root level package.json:
``
{
"private": true,
"workspaces": ["packages/*"]
}
``
In the subproject’s package.json you should use the name of the package you want to be linked in node_modules:
```
//packages/reference1/package.json
{
"name": "@myscope/reference1",
"version": "1.0.0",
"module": "lib/index.js
}
```
When you run yarn install the links in node_modules will be created for you.
You can now use your project references anywhere in your codebase with a simple import statement, exactly like you import npm modules. If you have a more complex application, for example with client and server applications, you can share modules easily.
### Building a Component Library
A common problem in code organisation is how to re-use code in multiple projects. Project references help toward this goal by providing a logical separation between components. This will mean you can drop a component into another project and use it. But there is still the matter of how you do this:
* You could copy the project reference folder into all top-level projects you want to use it in. This has the disadvantage that you end up with multiple copies of code. If you patch or enhance a component you need to copy the patch to all the other projects, rebuild them and test.
* Another approach would be to symlink the component into each top-level project. The downside of this is that once you amend the component you could break all of the projects which depend on it.
A smarter solution is to publish the components as npm packages. You can use semantic versioning each time you publish using a version in the format major.minor.patch. You then add the components to other projects using yarn add @myscope/reference1.
Versioning works exactly the same as any other npm package. You specify in the consuming project’s tsconfig.json what version changes are acceptable:
```
"@myscope/reference1": "1.0.1", // Only version 1.0.1 can be used
"@myscope/reference1": "~1.0.1", // Patch updates are acceptable
"@myscope/reference1": "^1.0.1", // Minor version changes are OK
```
You can then update and publish new versions of the component with new version numbers. The other project will not be broken as it will continue to use the version specified in its package.json. When you are ready to update you can use the same yarn tools you would use to update any package (yarn outdated / upgrade / upgrade-interactive or the npm equivalents).
If you want to keep your packages private you can set up your own private npm repository with [Verdaccio](https://verdaccio.org/) or you can use [Github Packages](https://github.com/features/packages)
### Lerna
If your project references are complex and have their own scripts for testing and building you could use [Lerna](https://lerna.js.org/). This works well with yarn workspaces and the project structure outlined above. If you have a test script in reference1 you could use the following command to execute it:
```
lerna run --scope=reference1 test
```
The same command without the --scope argument would execute the test scripts in all subprojects.
Yarn workspaces and Lerna introduce more power but also more complexity in the workflow. They are not required to use project references so it is up to you whether the extra learning curve they introduce is worthwhile.
### Build Times in Development
Using ts-loader and webpack-dev-server, when you change a file in one of the project references ts-loader will automatically rebuild the reference and include the change in the new bundle. Rebuilding the reference may take a few seconds. By comparison, when you change a file in the root source (non-reference) webpack will get ts-loader to rebuild just that file and create a new bundle very quickly, typically less than 1 second.
So if you are developing code in a reference and find the few seconds it takes to rebuild the reference too much, you could benefit from importing from the TypeScript source directly. This will be at the expense of longer warm start times as you will not be using the pre-built code for that referenced project.
ts-loader-9.4.2/RELEASING.md 0000664 0000000 0000000 00000003423 14341700417 0015256 0 ustar 00root root 0000000 0000000 # Publishing
So the time has come to publish the latest version of ts-loader to npm. Exciting!
Before you can actually publish make sure the following statements are true:
- 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.
OK - you're actually ready. We're going to publish. Here we need to tread carefully. Follow these steps:
- clone ts-loader from the main repo with this command: `git clone 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 `yarn install`
- build ts-loader with `yarn build`
- run the tests to ensure all is still good: `yarn test`
If all the tests 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` ([alas `yarn publish` doesn't seem to publish all the js to npm](https://github.com/TypeStrong/ts-loader/issues/654))
You've released! Pat yourself on the back. ts-loader-9.4.2/examples/ 0000775 0000000 0000000 00000000000 14341700417 0015237 5 ustar 00root root 0000000 0000000 ts-loader-9.4.2/examples/fork-ts-checker-webpack-plugin/ 0000775 0000000 0000000 00000000000 14341700417 0023134 5 ustar 00root root 0000000 0000000 ts-loader-9.4.2/examples/fork-ts-checker-webpack-plugin/.eslintrc.js 0000664 0000000 0000000 00000000417 14341700417 0025375 0 ustar 00root root 0000000 0000000 // Useful references:
// https://typescript-eslint.io/
module.exports = {
root: true,
parser: '@typescript-eslint/parser',
plugins: ['@typescript-eslint'],
extends: [
'eslint:recommended',
'plugin:@typescript-eslint/recommended',
'prettier',
],
};
ts-loader-9.4.2/examples/fork-ts-checker-webpack-plugin/.gitignore 0000664 0000000 0000000 00000000024 14341700417 0025120 0 ustar 00root root 0000000 0000000 /dist
/node_modules
ts-loader-9.4.2/examples/fork-ts-checker-webpack-plugin/.vscode/ 0000775 0000000 0000000 00000000000 14341700417 0024475 5 ustar 00root root 0000000 0000000 ts-loader-9.4.2/examples/fork-ts-checker-webpack-plugin/.vscode/settings.json 0000664 0000000 0000000 00000000342 14341700417 0027227 0 ustar 00root root 0000000 0000000 {
"eslint.autoFixOnSave": false,
"eslint.validate": [
"javascript",
"javascriptreact",
{ "language": "typescript", "autoFix": true },
{ "language": "typescriptreact", "autoFix": true }
]
} ts-loader-9.4.2/examples/fork-ts-checker-webpack-plugin/README.md 0000664 0000000 0000000 00000001054 14341700417 0024413 0 ustar 00root root 0000000 0000000 # fork-ts-checker-webpack-plugin / Jest
## Getting started
You'll need [node / npm](https://nodejs.org/) installed. To get up and running just enter:
```shell
# Download the npm packages you need (including the type definitions from DefinitelyTyped)
yarn install
# Compile the code and serve it up at http://localhost:8080
yarn start
# If you'd like to run your tests in watch mode then fire up a separate console and enter this command:
yarn test:watch
```
When you're building for production then `yarn build`. To run tests in CI then `yarn test` ts-loader-9.4.2/examples/fork-ts-checker-webpack-plugin/package.json 0000664 0000000 0000000 00000001767 14341700417 0025435 0 ustar 00root root 0000000 0000000 {
"name": "fork-ts-checker-webpack-plugin",
"version": "1.0.0",
"main": "dist/main.js",
"license": "MIT",
"scripts": {
"start": "webpack serve --mode=development",
"prebuild": "rimraf ./dist/*",
"build": "webpack --mode=production",
"lint": "eslint ./src"
},
"devDependencies": {
"@types/react": "^18.0.8",
"@types/react-dom": "^18.0.3",
"@typescript-eslint/eslint-plugin": "^5.21.0",
"@typescript-eslint/parser": "^5.21.0",
"eslint": "^8.14.0",
"eslint-config-prettier": "^8.5.0",
"eslint-plugin-react": "^7.29.4",
"fork-ts-checker-notifier-webpack-plugin": "^6.0.0",
"fork-ts-checker-webpack-plugin": "^7.2.8",
"html-webpack-plugin": "^5.5.0",
"prettier": "2.6.2",
"rimraf": "^3.0.2",
"ts-loader": "^9.2.9",
"tslib": "^2.4.0",
"typescript": "^4.6.4",
"webpack": "^5.72.0",
"webpack-cli": "^4.9.2",
"webpack-dev-server": "^4.8.1"
},
"dependencies": {
"react": "^18.1.0",
"react-dom": "^18.1.0"
}
}
ts-loader-9.4.2/examples/fork-ts-checker-webpack-plugin/src/ 0000775 0000000 0000000 00000000000 14341700417 0023723 5 ustar 00root root 0000000 0000000 ts-loader-9.4.2/examples/fork-ts-checker-webpack-plugin/src/app.tsx 0000664 0000000 0000000 00000000260 14341700417 0025241 0 ustar 00root root 0000000 0000000 import * as React from 'react';
import { Layout } from './components/layout';
export const App: React.FC = () => (