.json')`) can you do something like this:

```ts
import { sync as loadJsonFileSync } from 'load-json-file';

const { version } = loadJsonFileSync('../../package.json');
```

TypeScript won't care about it being outside of the `rootDir` this way.

https://github.com/sindresorhus/load-json-file

If you want to avoid hardcoding all the `../..` you can try this:
https://github.com/sindresorhus/read-pkg-up
<issue_comment>username_25: @username_7 I can't set it to "src" as mentioned above. I am importing "package.json" outside our src (`import pkg from '../package.json';`) and tsc does not allow that.

Thanks for sharing this @username_28! I will try it.
<issue_comment>username_29: @username_7  But it is what `rootDir` **should** mean, and this is what this issue is about.
<issue_comment>username_30: Here's a thought: add an option to the "compilerOptions" that allows me to tell the compiler what it should do with that error message. I have a few thoughts in mind, though the most polite one would be to simply ignore it because in my use case I don't need that error message.

Keep that option disabled and you won't break any existing setups. And for people like me, who are sick and tired of seeing this error message return every 6 months, the problem is solved.

As I see it, the only question that's left is to compare use cases and see if this is the best solution and/or if there are other flags that may be necessary. Can we do that and fix this issue? I'm tired of seeing these random errors pop up in my IDE. I really do have better things to do than to post here, you know.
<issue_comment>username_30: I'm not that good at maintaining my composure when I see issues that have been open since 2016 that could probably be very fixed without introducing new issues for existing users by introducing a new "compilerOption" to let the compiler know it can ignore the error in a given use case.

For this, I apologize. I can't help it, because I'm relied upon to provide a good service, yet I occasionally encounter issue threads like these. Why is it so difficult for the authors of TypeScript to implement one simple configuration flag?

I don't think it's because the developers are lazy, or because they're unwilling to help. I don't think anyone here is a bad person, except for myself.

It's this conflict, this debate, which has gone on for years over what appears to be the definition of the property "rootDir". And what to do about this issue.

People get thrown into this debate because they believe that they are right. Yes, "rootDir" serves as the base directory for the source code. Yes, the error is valid.

Yet, the underlying issue still persists. My tooling compiles the code perfectly, yet my IDE displays this error on my screen. It's a perversion. I want those red lines gone. My files don't have errors in them. And if they do, I should focus on those rather than being distracted by these non-issues.

All I want is to suppress this error message. I think that's what most of us want. I don't know if there are other cases here and maybe there are people who would like to speak up about that.

Can we please work together and solve this problem? It would make me so happy to see those red lines gone...
<issue_comment>username_6: @username_30 If `tsc` works but your IDE is showing your red squigglies then it means your IDE is not using the same compiler version or configuration as `tsc`.
<issue_comment>username_7: @username_30 file a bug that shows how to reproduce the problem and we will either fix it or tell you what's wrong with your project configuration
<issue_comment>username_31: Following on from @username_25 workaround, here is is a variation that is suitable to go inside your npm scripts

``` bash
tsc --module commonjs --target ESNext --outDir./edition-esnext --project tsconfig.json && test -d edition-esnext/source && ( mv edition-esnext/source edition-temp && rm -Rf edition-esnext && mv edition-temp edition-esnext ) || true
```
<issue_comment>username_30: **The solution is [Project References](https://www.typescriptlang.org/docs/handbook/project-references.html).**

To use this, edit your "tsconfig.json" file and add this to the end of the file (outside of the "compilerOptions"):

```
"references": [
	{ "path": "../common" }
]
```

This will allow you to reference files in the "../common/" folder (and all sub-folders).

---

My earlier confusion was stemming from the fact that IntelliJ and my untainted `gulp-typescript` task were giving me different results despite using the same "tsconfig.json" file.

It turns out that for some reason, "gulp-typescript" is trying a best-effort approach to compilation.

An error in TypeScript (such as `let z: number = ''`) will be flagged in IntelliJ but "gulp-typescript" compiles it just fine.
Only JavaScript syntax errors (such as `let 1z = ''`) are flagged by "gulp-typescript".

So, if you're a "gulp-typescript" user, you may experience such an issue depending on your version of "gulp-typescript" and your configuration. (I'm using the latest version at the time of writing, but I'm assuming someone from the future might be reading this. I hope times are better for you.)

---

I know the use of Project References is buried somewhere in this avalanche of responses, but it would have been better if this were documented better.

The top 3 results for "TS6059" on Google all lead to GitHub issues. It would have been a lot clearer to me if there was a page documenting these common errors and their solutions.

@username_6 Is this something that can be addressed? Should I make a new issue, or is this something that would go faster if it were discussed internally between the main contributors?
<issue_comment>username_6: (FWIW I'm not part of the TypeScript team)

Generally, I recommend against using `path`s unless you absolutely have to.  I believe its purpose is to allow for compatibility with legacy JS projects with weird dependency structures but I don't believe its intended to be used on any new projects, and if you find yourself needing it you may want to consider migrating away from it when you have the opportunity.  I don't use it personally so I can't really help with issues you may have with it, but I have seen lots of people struggle with it and the solution is usually "stop using it".

As for gulp-typescript, it sounds like perhaps the version of TSC being used by gulp-typescript is different from the version of TSC being used by IntelliJ.  When you see symptoms like you describe, that is usually the problem (the other being that they are not using the same `tsconfig.json`).
<issue_comment>username_30: The version used by "gulp-typescript" should be identical; both versions are derived from `node_modules`. I've tried various ways both of catching errors and modifying settings related to it (including messing around with the various "reporters" provided by "gulp-typescript" and attempting to override settings to emit more errors. Nothing seems to work.

It's fine though. As long as IntelliJ gives me errors, I'm happy to accept that the Gulp task will ignore them.

---

I'm not a fan of overhauling my method in favour of the preferred method of the week. The project structure I have makes sense to me. It keeps everything contained yet gives me the flexibility to split things up into multiple components.

I don't believe in "allowing compatibility for legacy reasons," and especially when it comes to project references. It _must_ be possible to reference files outside of the `rootDir` or you're simply not going to have the freedom to define the project structure in a way that makes sense to you & your team.

---

When I first began working with TypeScript, I ran into numerous issues. Among them:

- For including JavaScript files the go-to solution seemed to be AMD at the time. The website sounded official and there were many examples online of AMD in production use. But apparently, Webpack was the new big thing and so [some projects](https://github.com/zxing-js/library/issues/96) simply didn't work in an AMD environment. Lesson learned: Not everyone is going to adopt the new method, so you're always screwed.

- The road from TypeScript to the finalized minified JavaScript (