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.

[jmc420]

I found my issue and it was because the filesGlob was correctly picking up a file that I did not want included.

[MrHen]

I would also like a way to disable this warning. I have two scenarios where I want this:

• Running tests using mocha --require ts-node/register
• Using a gulpfile.ts (also with ts-node)

I explicitly don't want atom-typescript to build these files so I choose not to add them in my tsconfig.json's filesGlob.

My workaround for the test files was to just throw them away after the build was over but gulpfile.ts lives at the root level and my tsconfig.json has both rootDir and outDir set to something lower than the root.

I am reluctant to modify my tsconfig.json simply to keep an error from appearing in atom-typescript. I would like a way to disable this warning entirely or at least add a way to disable it for a particular file.

[cvharris]

The behavior asked for sounds like how jshint lets you configure which linting warnings you want to see or not. That, and just because atom-typescript is unaware how a file is being used doesn't mean there's an error. Either approach might resolve this issue.

[O4epegb]

With typescript 2 you can workaround this issue by having two tsconfig files, one for lib files + spec.files (for example) and the second one with only lib files, which you will use for compilation and where you ignore .spec files. Is was not possible before, because there were no glob patters, only with atom plugin, but atom plugin can't work with two configs at the same time, so again, that was impossible.
Maybe there is something smarter but right now i am doing this hack :)

[ibqn]

This warning messages are really annoying, and I can not really get rid of them ...

[jkwaldrip]

This is an issue for me as well. I can understand needing to keep the warning for other users, but it would be very helpful for me to have a way to selectively suppress this one warning.

I keep a test/ directory that has to be intentionally left out of TSConfig, and I need to lint these files according to our team's custom definitions without having them be part of the TS compilation context. Seeing this error for every file I have open in test/ is a distraction from being alerted to real errors that I need to be aware of.

Would it be possible to add a button in config to just suppress this specific warning? It seems like there are a few people on this thread it would be helpful for.

[demisx]

We would like to be able to disable errors/warnings per file/per line for some files. We use preprocessors for environment configuration files a lot and currently they all generate TS error messages. Here is an example of such file:

import { OpaqueToken } from '@angular/core';

// Opaque token is needed for DI token, since there is no class
export const APP_CONFIG_TOKEN = new OpaqueToken('appConfig');

export const APP_CONFIG = {
  // @if NODE_ENV='development'
  apiBasePath:  'http://localhost:3000/1.0',
  // @endif

  // @if NODE_ENV='staging'
  apiBasePath:  'https://staging.com/1.0', // <- Duplicate identifier error
  // @endif

  // @if NODE_ENV='production'
  apiBasePath:  'https://production.com/1.0', // <- Duplicate identifier error
  // @endif

};

[guncha]

I'm closing this since the original issue isn't an issue anymore. No warnings are generated in the case you're editing a file that's not part of a project. The status bar will look something like this:

@demisx what you're trying to accomplish could be done using a Typescript language service plugin feature that recently landed in 2.3.0. It's not well documented, but they idea is that you're able to intercept calls to getDiagnostics and, in your case, filter out messages based on a file and diagnostic type. If someone implements a plugin like that, it will immediately work in atom-typescript, VSCode, SublimeText and other editors that use tsserver, which is why I think this shouldn't be a part of atom-typescript.

[demisx]

Having two different tsconfig.json suggested by @O4epegb fixed the issue. Basically, the build version should be different from the default one used by Atom Typescript.