Disable warning for TypeScript file not within `tsconfig.json`

[blakeembrey]

I would love to be able to write and run my tests using typescript-node, which works perfectly, except atom-typescript continues to warn my to check if it should be in the files array. This wouldn't be a big deal, except it then disable completion and linting for the rest of the file. Can we not consider any tsconfig.json in the current directory upward part of the configuration automatically?

I imagine you can run into a similar casing when compiling TypeScript within a Browserify/Webpack/etc. project since you don't need to define the files for it to work there.

[basarat]

Webpack/etc.

This tsloader expects a tsconfig.json : https://github.com/jbrantly/ts-loader#configuration

Can we not consider any tsconfig.json in the current directory upward part of the configuration automatically

We can and already do a bit ... just remove files && filesGlob for the tsconfig and an implict glob is used that contains all the files. Let me know if that doesn't work out.

[blakeembrey]

@basarat Yes, they definitely work with tsconfig.json for references - but it's not needed for input files since they are defined by Webpack (I wrote one here also, https://github.com/blakeembrey/typescript-simple-loader). I was doing the implicit glob as a hack to work around it, but then I have issues with the compilation outDir. Using rootDir does not help there.

[basarat]

Disable warning for TypeScript file not within `tsconfig.json

Not sure why one would want to disable a useful warning? Basically we are saying there is no tsconfig file for this .ts file? < which seems like a good idea

[blakeembrey]

@basarat Sorry, that title isn't the best. It's more a side effect. I'm just brainstorming whether there could be a better way to read from tsconfig.json and have things still work assuming it's not explicitly listed in files.

[basarat]

I'm just brainstorming whether there could be a better way to read from tsconfig.json and have things still work assuming it's not explicitly listed in files.

Basically we are in the same situation as not having a tsconfig ... just that the tsconfig is misconfigured. And that isn't supported atm 🌹 Definitely want to keep the warning as its a configuration error .... but probably want to support lose .ts files at some point 🌹

[nycdotnet]

Blake - would it be better if it wasn't an error (in the linter list), but perhaps a "watermark" or something? I'm not sure this would actually change the behavior, but it might "feel" better. For example, look at the watermarks provided by this Visual Studio extension. https://visualstudiogallery.msdn.microsoft.com/65748cdb-4087-497e-a394-2e3449c8e61e

Bas - to support loose files, would we have to keep two language services in memory? One with the real tsconfig and one for any loose .ts files?

[blakeembrey]

That could be interesting to see, maybe.

As for the actual behaviour, I'm also ok with treating it as if there is no tsconfig file too. I haven't played around with too many editors and the TypeScript plugins, are there any that work with defaults or resolve up instead of tsconfig.files? The filesGlob feature, I think, solves the explicit issue I have, it's just not transportable so I'm ok if this is closed too.

[basarat]

to support loose files, would we have to keep two language services in memory

@nycdotnet No a separate project per loose file. Like we currently do for loose .d.ts files

[basarat]

@nycdotnet code :

atom-typescript/lib/main/tsconfig/tsconfig.ts

Lines 302 to 326 in e0e603e

	export function getDefaultInMemoryProject(srcFile: string): TypeScriptProjectFileDetails {
	var dir = fs.lstatSync(srcFile).isDirectory() ? srcFile : path.dirname(srcFile);
	var files = [srcFile];
	var typings = getDefinitionsForNodeModules(dir, files);
	files = increaseProjectForReferenceAndImports(files);
	files = uniq(files.map(fsu.consistentPath));
	let project: TypeScriptProjectSpecification = {
	compilerOptions: defaults,
	files,
	typings: typings.ours.concat(typings.implicit),
	formatCodeOptions: formatting.defaultFormatCodeOptions(),
	compileOnSave: true,
	buildOnSave: false,
	scripts: {}
	};
	return {
	projectFileDirectory: dir,
	projectFilePath: dir + '/' + projectFileName,
	project: project,
	inMemory: true
	};
	}

🌹

But it might be missing massive developer ergonomics for .ts files :)

[JaKXz]

+1 for atom-typescript acknowledging the ! operator in the filesGlobs, since it's safe to put that in tsconfig.json for tsc and would make life a little bit easier. Apologies for the duplicate issue noise.

[jmc420]

does file exclusion in the tsconfig working atom-typescript version 7.14.1? I have this file exclusion but it is still compiling my typings directory:

"filesGlob": [
"./src/ts//*.ts",
"!./node_modules//.ts",
"!./typings/__/.ts"
],

when I run tsc on the command line, it works fine. Is there something wrong with the filesGlob above?

James

[blakeembrey]

This is the wrong issue for filesGlob issues. There's no known issues with filesGlob right now. I don't understand you're problem - can you open an issue and say what's wrong instead of just that it isn't. Then we can narrow the issue down. That filesGlob you posted though, it doesn't need those exclusions at all since you aren't including them to begin with. Also, tsc does not use filesGlob, it's purely an atom-typescript thing.