Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

ts-loader

Package Overview
Dependencies
Maintainers
3
Versions
165
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

ts-loader - npm Package Compare versions

Comparing version 6.0.4 to 6.1.0

3

CHANGELOG.md
# Changelog
## v6.1.0
* [Build upstream project references with SolutionBuilder](https://github.com/TypeStrong/ts-loader/pull/935) (#851, #913) - thanks @sheetalkamat!
## v6.0.4

@@ -4,0 +7,0 @@ * [Fix issue when handling files not included in tsconfig.json](https://github.com/TypeStrong/ts-loader/issues/943) (#934) - thanks @davazp!

@@ -55,2 +55,9 @@ "use strict";

}
if (configParseResult.options.configFile) {
Object.defineProperty(compilerOptions, 'configFile', {
enumerable: false,
writable: false,
value: configParseResult.options.configFile
});
}
return compilerOptions;

@@ -57,0 +64,0 @@ }

@@ -5,2 +5,3 @@ "use strict";

const semver = require("semver");
const compilerSetup_1 = require("./compilerSetup");
const utils_1 = require("./utils");

@@ -97,2 +98,12 @@ function getConfigFile(compiler, colors, loader, loaderOptions, compilerCompatible, log, compilerDetailsLogMessage) {

exports.getConfigParseResult = getConfigParseResult;
const extendedConfigCache = new Map();
function getParsedCommandLine(compiler, loaderOptions, configFilePath) {
const result = compiler.getParsedCommandLineOfConfigFile(configFilePath, loaderOptions.compilerOptions, Object.assign(Object.assign({}, compiler.sys), { onUnRecoverableConfigFileDiagnostic: () => { } // tslint:disable-line no-empty
}), extendedConfigCache);
if (result) {
result.options = compilerSetup_1.getCompilerOptions(result);
}
return result;
}
exports.getParsedCommandLine = getParsedCommandLine;
//# sourceMappingURL=config.js.map

2

dist/index.js

@@ -297,3 +297,3 @@ "use strict";

const { outputText, sourceMapText, diagnostics } = instance.compiler.transpileModule(contents, {
compilerOptions: Object.assign({}, instance.compilerOptions, { rootDir: undefined }),
compilerOptions: Object.assign(Object.assign({}, instance.compilerOptions), { rootDir: undefined }),
transformers: instance.transformers,

@@ -300,0 +300,0 @@ reportDiagnostics: true,

@@ -159,2 +159,9 @@ "use strict";

}
if (configFilePath && utils_1.supportsSolutionBuild(loaderOptions, compiler)) {
// Use solution builder
log.logInfo('Using SolutionBuilder api');
instance.configFilePath = configFilePath;
instance.solutionBuilderHost = servicesHost_1.makeSolutionBuilderHost(scriptRegex, log, loader, instance);
instance.solutionBuilder = compiler.createSolutionBuilderWithWatch(instance.solutionBuilderHost, [configFilePath], { verbose: true, watch: true });
}
if (loaderOptions.experimentalWatchApi && compiler.createWatchProgram) {

@@ -161,0 +168,0 @@ log.logInfo('Using watch api');

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
const path = require("path");
const config_1 = require("./config");
const constants = require("./constants");

@@ -248,2 +249,33 @@ const resolver_1 = require("./resolver");

exports.makeWatchHost = makeWatchHost;
/**
* Create the TypeScript Watch host
*/
function makeSolutionBuilderHost(scriptRegex, log, loader, instance) {
const { compiler, compilerOptions, appendTsTsxSuffixesIfRequired, loaderOptions: { resolveModuleName: customResolveModuleName, resolveTypeReferenceDirective: customResolveTypeReferenceDirective } } = instance;
// loader.context seems to work fine on Linux / Mac regardless causes problems for @types resolution on Windows for TypeScript < 2.3
const getCurrentDirectory = () => loader.context;
const formatDiagnosticHost = {
getCurrentDirectory: compiler.sys.getCurrentDirectory,
getCanonicalFileName: compiler.sys.useCaseSensitiveFileNames
? s => s
: s => s.toLowerCase(),
getNewLine: () => compiler.sys.newLine
};
const reportDiagnostic = (d) => log.logError(compiler.formatDiagnostic(d, formatDiagnosticHost));
const reportSolutionBuilderStatus = (d) => log.logInfo(compiler.formatDiagnostic(d, formatDiagnosticHost));
const reportWatchStatus = (d, newLine, _options) => log.logInfo(`${compiler.flattenDiagnosticMessageText(d.messageText, compiler.sys.newLine)}${newLine + newLine}`);
const solutionBuilderHost = compiler.createSolutionBuilderWithWatchHost(compiler.sys, compiler.createEmitAndSemanticDiagnosticsBuilderProgram, reportDiagnostic, reportSolutionBuilderStatus, reportWatchStatus);
solutionBuilderHost.getCurrentDirectory = getCurrentDirectory;
solutionBuilderHost.trace = logData => log.logInfo(logData);
solutionBuilderHost.getParsedCommandLine = file => config_1.getParsedCommandLine(compiler, instance.loaderOptions, file);
// make a (sync) resolver that follows webpack's rules
const resolveSync = resolver_1.makeResolver(loader._compiler.options);
const resolvers = makeResolvers(compiler, compilerOptions, solutionBuilderHost, customResolveTypeReferenceDirective, customResolveModuleName, resolveSync, appendTsTsxSuffixesIfRequired, scriptRegex, instance);
// used for (/// <reference types="...">) see https://github.com/Realytics/fork-ts-checker-webpack-plugin/pull/250#issuecomment-485061329
solutionBuilderHost.resolveTypeReferenceDirectives =
resolvers.resolveTypeReferenceDirectives;
solutionBuilderHost.resolveModuleNames = resolvers.resolveModuleNames;
return solutionBuilderHost;
}
exports.makeSolutionBuilderHost = makeSolutionBuilderHost;
function makeResolveTypeReferenceDirective(compiler, compilerOptions, moduleResolutionHost, customResolveTypeReferenceDirective) {

@@ -307,3 +339,3 @@ if (customResolveTypeReferenceDirective === undefined) {

return {
moduleResolutionHost: Object.assign({}, servicesHost, { fileExists: createCache(servicesHost.fileExists), directoryExists: servicesHost.directoryExists &&
moduleResolutionHost: Object.assign(Object.assign({}, servicesHost), { fileExists: createCache(servicesHost.fileExists), directoryExists: servicesHost.directoryExists &&
createCache(servicesHost.directoryExists), realpath: servicesHost.realpath && createCache(servicesHost.realpath) }),

@@ -310,0 +342,0 @@ clearCache: () => clearCacheFunctions.forEach(clear => clear())

@@ -16,2 +16,3 @@ import { Chalk } from 'chalk';

export declare function getConfigParseResult(compiler: typeof typescript, configFile: ConfigFile, basePath: string, configFilePath: string | undefined, enableProjectReferences: boolean): typescript.ParsedCommandLine;
export declare function getParsedCommandLine(compiler: typeof typescript, loaderOptions: LoaderOptions, configFilePath: string): typescript.ParsedCommandLine | undefined;
export {};

@@ -1,2 +0,2 @@

export { ModuleResolutionHost } from 'typescript';
export { ModuleResolutionHost, FormatDiagnosticsHost } from 'typescript';
import * as typescript from 'typescript';

@@ -72,2 +72,5 @@ import { Chalk } from 'chalk';

changedFilesList?: boolean;
solutionBuilderHost?: typescript.SolutionBuilderWithWatchHost<typescript.EmitAndSemanticDiagnosticsBuilderProgram>;
solutionBuilder?: typescript.SolutionBuilder<typescript.EmitAndSemanticDiagnosticsBuilderProgram>;
configFilePath?: string;
}

@@ -74,0 +77,0 @@ export interface LoaderOptionsCache {

@@ -18,1 +18,5 @@ import * as typescript from 'typescript';

export declare function makeWatchHost(scriptRegex: RegExp, log: logger.Logger, loader: webpack.loader.LoaderContext, instance: TSInstance, projectReferences?: ReadonlyArray<typescript.ProjectReference>): WatchHost;
/**
* Create the TypeScript Watch host
*/
export declare function makeSolutionBuilderHost(scriptRegex: RegExp, log: logger.Logger, loader: webpack.loader.LoaderContext, instance: TSInstance): typescript.SolutionBuilderWithWatchHost<typescript.EmitAndSemanticDiagnosticsBuilderProgram>;

@@ -45,2 +45,3 @@ import { Chalk } from 'chalk';

export declare function validateSourceMapOncePerProject(instance: TSInstance, loader: webpack.loader.LoaderContext, jsFileName: string, project: typescript.ResolvedProjectReference): void;
export declare function supportsSolutionBuild(loaderOptions: LoaderOptions, compiler: typeof typescript): boolean;
/**

@@ -47,0 +48,0 @@ * Gets the output JS file path for an input file governed by a composite project.

@@ -162,2 +162,5 @@ "use strict";

function ensureProgram(instance) {
if (instance.solutionBuilder) {
instance.solutionBuilder.buildReferences(instance.configFilePath);
}
if (instance && instance.watchHost) {

@@ -250,2 +253,6 @@ if (instance.hasUnaccountedModifiedFiles) {

exports.validateSourceMapOncePerProject = validateSourceMapOncePerProject;
function supportsSolutionBuild(loaderOptions, compiler) {
return !!loaderOptions.projectReferences && !!compiler.InvalidatedProjectKind;
}
exports.supportsSolutionBuild = supportsSolutionBuild;
/**

@@ -252,0 +259,0 @@ * Gets the output JS file path for an input file governed by a composite project.

{
"name": "ts-loader",
"version": "6.0.4",
"version": "6.1.0",
"description": "TypeScript loader for webpack",

@@ -12,4 +12,5 @@ "main": "index.js",

"comparison-tests-generate": "node test/comparison-tests/stub-new-version.js",
"execution-tests": "node test/execution-tests/run-tests.js",
"test": "node test/run-tests.js",
"execution-tests": "git clean -xfd test/execution-tests && node test/execution-tests/run-tests.js",
"test": "git clean -xfd test/execution-tests && node test/run-tests.js",
"clean": "git clean -xfd test/execution-tests",
"docker:build": "docker build -t ts-loader .",

@@ -92,3 +93,3 @@ "postdocker:build": "docker run -it ts-loader yarn test"

"tslint-config-prettier": "^1.15.0",
"typescript": "^3.5.2",
"typescript": "^3.6.2",
"webpack": "^4.5.0",

@@ -95,0 +96,0 @@ "webpack-cli": "^3.1.1"

@@ -32,3 +32,3 @@ # TypeScript loader for webpack

### Yarn Plug’n’Play
### Yarn Plug’n’Play

@@ -45,3 +45,3 @@ `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).

But if that's what you want to do, there's two ways to achieve this: [happypack](https://github.com/amireh/happypack) and [thread-loader](https://github.com/webpack-contrib/thread-loader). Both should be used in combination with [fork-ts-checker-webpack-plugin](https://github.com/Realytics/fork-ts-checker-webpack-plugin) for typechecking.)
But if that's what you want to do, there's two ways to achieve this: [happypack](https://github.com/amireh/happypack) and [thread-loader](https://github.com/webpack-contrib/thread-loader). Both should be used in combination with [fork-ts-checker-webpack-plugin](https://github.com/Realytics/fork-ts-checker-webpack-plugin) for typechecking.)

@@ -256,3 +256,3 @@ To read more, look at [this post](https://medium.com/webpack/typescript-webpack-super-pursuit-mode-83cc568dea79) by [@johnny_reilly](https://twitter.com/johnny_reilly) on the webpack publication channel.

It's advisable to use this with the [fork-ts-checker-webpack-plugin](https://github.com/Realytics/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 simple HappyPack example](examples/happypack) / [our simple thread-loader example](examples/thread-loader). For a more complex setup take a look at our [more involved HappyPack example](examples/react-babel-karma-gulp-happypack) / [more involved thread-loader example](examples/react-babel-karma-gulp-thread-loader). **_IMPORTANT_**: If you are using fork-ts-checker-webpack-plugin alongside HappyPack or thread-loader then ensure you set the `checkSyntacticErrors` option like so:
It's advisable to use this with the [fork-ts-checker-webpack-plugin](https://github.com/Realytics/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 simple thread-loader example](examples/thread-loader). **_IMPORTANT_**: If you are using fork-ts-checker-webpack-plugin alongside HappyPack or thread-loader then ensure you set the `checkSyntacticErrors` option like so:

@@ -575,30 +575,4 @@ ```javascript

**TL;DR:** Using project references currently requires building referenced projects outside of ts-loader. We don’t want to keep it that way, but we’re releasing what we’ve got now. To try it out, you’ll need to pass `projectReferences: true` to `loaderOptions`. You’ll also probably need to use TypeScript 3.1.1 or later (which, as of this writing, means `typescript@next`).
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.
ts-loader has partial support for [project references](https://www.typescriptlang.org/docs/handbook/project-references.html) in that it will _load_ dependent composite projects that are already built, but will not currently _build/rebuild_ those upstream projects. The best way to explain exactly what this means is through an example. Say you have a project with a project reference pointing to the `lib/` directory:
```
tsconfig.json
app.ts
lib/
tsconfig.json
niftyUtil.ts
```
And we’ll assume that the root `tsconfig.json` has `{ "references": { "path": "lib" } }`, which means that any import of a file that’s part of the `lib` sub-project is treated as a reference to another project, not just a reference to a TypeScript file. Before discussing how ts-loader handles this, it’s helpful to review at a really basic level what `tsc` itself does here. If you were to run `tsc` on this tiny example project, the build would fail with the error:
```
error TS6305: Output file 'lib/niftyUtil.d.ts' has not been built from source file 'lib/niftyUtil.ts'.
```
Using project references actually instructs `tsc` _not_ to build anything that’s part of another project from source, but rather to look for any `.d.ts` and `.js` files that have already been generated from a previous build. Since we’ve never built the project in `lib` before, those files don’t exist, so building the root project fails. Still just thinking about how `tsc` works, there are two options to make the build succeed: either run `tsc -p lib/tsconfig.json` _first_, or simply run `tsc --build`, which will figure out that `lib` hasn’t been built and build it first for you.
Ok, so how is that relevant to ts-loader? Because the best way to think about what ts-loader does with project references is that it acts like `tsc`, but _not_ like `tsc --build`. If you run ts-loader on a project that’s using project references, and any upstream project hasn’t been built, you’ll get the exact same `error TS6305` that you would get with `tsc`. If you modify a source file in an upstream project and don’t rebuild that project, `ts-loader` won’t have any idea that you’ve changed anything—it will still be looking at the output from the last time you _built_ that file.
**“Hey, don’t you think that sounds kind of useless and terrible?”** Well, sort of. You can consider it a work-in-progress. It’s true that on its own, as of today, ts-loader doesn’t have everything you need to take advantage of project references in webpack. In practice, though, _consuming_ upstream projects and _building_ upstream projects are somewhat separate concerns. Building them will likely come in a future release. For background, see the [original issue](https://github.com/TypeStrong/ts-loader/issues/815).
**`outDir` Windows problemo.** At the moment, composite projects built using the [`outDir` compiler option](https://www.typescriptlang.org/docs/handbook/compiler-options.html) cannot be consumed using ts-loader on Windows. If you try to, ts-loader throws a "has not been built from source file" error. We don't know why yet; it's possible there's a bug in `tsc`. It's more likely there's a bug in `ts-loader`. Hopefully it's going to get solved at some point. (Hey, maybe you're the one to solve it!) Either way, we didn't want to hold back from releasing. So if you're building on Windows then avoid building `composite` projects using `outDir`.
**TypeScript version compatibility.** As a final caveat, [this commit to TypeScript](https://github.com/Microsoft/TypeScript/commit/d519e3f21ec36274726c44dab25c9eb48e34953f) is necessary for the `include` or `exclude` options of a project-referenced tsconfig file to work. It should be released in TypeScript 3.1.1 according to the tags. To use an earlier version of TypeScript, referenced project configuration files must specify `files`, and not `include`.
### Usage with webpack watch

@@ -621,11 +595,9 @@

To enable `webpack-dev-server` HMR, you need to follow the official [webpack HMR guide](https://webpack.js.org/guides/hot-module-replacement/), then tweak a few config options for `ts-loader`. The required configuration is as follows:
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-boolean-defaultfalse) for config details and recommendations above).
2. Inside your HMR acceptance callback function, you must re-require the module that was replaced.
2. Inside your HMR acceptance callback function, maybe re-require the module that was replaced.
For a boilerplate HMR project using React, check out the [react-hot-boilerplate example](./examples/react-hot-boilerplate/).
For a minimal HMR TypeScript setup, go to the [hot-module-replacement example](./examples/hot-module-replacement/).
## Contributing

@@ -632,0 +604,0 @@

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc