avivahl / ts-tools Goto Github PK

It looks like the isolated flag skips type-checking and also skips tsconfig lookup.

Is there a way to perform tsconfig lookup (for flags like downlevelIteration and target that affect emitted code) but still skip type-checking?

Could u please open API for build, it really helps me to wrap process inside my own build scripts ? WDYT ?:)

move code from ``cli.ts` line 32 to build.ts scripts
https://github.com/AviVahl/ts-tools/blob/main/packages/build/src/cli.ts#L32

Do you plan to support watch mode ?

Is there way somehow apply plugin for transform files ?
Target is renaming scss import to css after successfully compiling js.
I want to run concurrently for ex. building css by gulp with node-sass

Or better to play with @ts-tools/transpile before running build script ?

Sorry for a lot of question, hope u are doing best :)

The JSDoc for TypeScript service says I can pass options to the constructor, but it doesn't have one.
https://github.com/AviVahl/ts-tools/blob/master/packages/service/src/service.ts#L60

Is this something coming in a future version, or did you decide to go for a different API?

Hi, hope u are doing well :)

Could we make API for applying react-refresh-plugin like did ts-loader

{
    loader: require.resolve('ts-loader'),
      options: {
         getCustomTransformers: () => ({
            before: isDevelopment ? [ReactRefreshTypeScript()] : [],
          }),
      }, 
},

is it possible to use ttypescript transformers?

I'm using this excellent webpack-loader for a monorepo, and ran into a bit of a configuration snafu. Some of the monorepo packages are ejected Create React App projects, and I migrated to this from other ts loaders, so I was passing in the configFileName as defined by the React paths (which are just normalized absolute paths).

For awhile this was fine, as I was only importing one linked project into another, a single level deep (A imports B). Recently, however, I added a nested linked dependency (A imports B imports C), and I started getting errors (can't find C from B).

Long story short, after a bunch of debugging, I found that this issue was related to tsconfig lookups. When passing an absolute path as configFileName, all lookups resolve to that config file and therefore nested path resolution breaks. Maybe this should have been obvious, and knowing how the lookup algorithm works, it certainly is, but it tripped me up for quite awhile nonetheless. The obvious solution in my case was to simply remove configFileName from the webpack configurations, and the lookup algorithm did its job perfectly.

I suppose this is probably an edge case. For example, I assume everything would also work if configFileName were simply the file name itself, and all config file names had the same name (not super unreasonable). However, I believe this could be an issue if the config file names were different across linked projects. One example that comes to mind is Angular, where it's common to have a tsconfig.aot.json. In this case, if a dependency did not have this file name, it would presumably fail. To make this work, we might need to have configFileName accept a function.

Anyways, at the very least I wanted to log this issue in case someone else runs into it. Feel free to close this, and thanks for the great loader.

This is a situation I've encountered that actually has an easy workaround, but I thought I'd share it in case anyone else is trying to do the same.

Use-case

I want to discover the tsconfig for a directory, get the parsed compiler options, and get a list of source files.

Right now, the API leads one to believe that they must know the name of a source file first, rather than discovering the source files from the tsconfig.

Workaround

Try to parse a .ts file that you know does not exist. This will trigger tsconfig discovery and the creation of a language service.

import { TypeScriptService } from '@ts-tools/service';
const service = new TypeScriptService();
service.transpileFile('DOES NOT EXIST.ts', {
  tsconfigFileName : 'tsconfig.json',
  getCompilerOptions = (baseHost, tsconfigOptions) =>tsconfigOptions
});
const runningService = service.runningServices.get('tsconfig.json')!;
// Grab parsed compilerOptions
console.dir(runningService.languageService.getProgram()!.getCompilerOptions());
// Grab parsed set of source files
console.dir(runningService.rootFileNames);

With the new 1.0.0 version, Webpack warns on missing export for a re-export of a type definition with no runtime alias. For example:

/*internal.ts*/
export type SomeType = any;
/*re-export.ts*/
export { SomeType } from './internal';
/*main.ts*/
import {SomeType} from './re-export';
/*
WARNING in ./index.ts                                                                                                                                              
 export 'SomeType' was not found in './internal'
 @ ./main.ts
 @ multi ./main.ts
*/

I think this happens because type exports are erased from the origin file on transform, but kept as dependencies at the end module that used the definition. but I'm not sure when are they being erased in the normal flow.

Maybe a solution could be to have the on-the-fly transpilation replace type exports with runtime symbols for dev?

Workaround

Changing the re-export can prevent this:

/*re-export.ts*/
export * from './internal';

// OR

import { SomeType } from './internal';
export type SomeType = SomeType

I thought about putting a filter in the Webpack configuration, but that would also hide real import misses.

Does node-typescript-support support path map in tsconfig.json file?

https://github.com/Microsoft/TypeScript/wiki/FAQ#why-am-i-getting-the-error-ts5055-cannot-write-file-xxxjs-because-it-would-overwrite-input-file-when-using-javascript-files

as Result we got issue
error TS5055: Cannot write file '**/*.js' because it would overwrite input file.

Need to set outDir depends on arguments (--cjs or --esm)

I tried calling service.transpileFile:

service.transpileFile('src/foo.ts', {
  isolated: true,
  tsconfigFileName: 'tsconfig.json',
  getCompilerOptions(baseHost, tsconfigOptions) {
    return tsconfigOptions;
  }
});

I wanted it to use my tsconfig config, so I implemented getCompilerOptions to return the tsconfigOptions passed to it. Unfortunately, this causes a type error because the argument is read-only, whereas I must return a mutable object. I think changing the return type signature to be Readonly<> would fix the problem.

basing of the discussion in #191, regarding caching when applying transformers, would it be possible to override the logic of choosing the cache name any apply it as an option to the loader?

It could solve the caching issue when having for example the same ts config with a dev config that has the react refresh transformation and a production config that doesn't