Custom tsconfig.json about deno HOT 24 CLOSED

@jedmao Deno doesn't have that logic yet - it only uses one built in set of tsconfig. Coming soon.

from deno.

It is being worked on.

from deno.

currently, the ts config is hardcoded in runtime.ts
https://github.com/ry/deno/blob/e3926720118f76e4b1352a75e332026e49154f34/runtime.ts#L183-L191

from deno.

Talking to @ry, we discussed that option 1 listed above is a better approach. Deno will support the tsconfig.json. There are certain compiler options which we cannot support or allow to be modified that have to deal with how code is emitted. When a tsconfig.json provides one of these, we will ignore it, but log out a warning that the option is ignored.

from deno.

@zheeeng I was thinking how to write module imports that will support both, node & deno, and thats brilliant idea using tscofnig paths it can be done very easily, in future I already plan to organize code so to support both platforms (until there will be stable version of deno) and I think supporting paths is very important

from deno.

@jedmao I will deal with it.

from deno.

Expect on this improvement. I'm wondering how will the module system handle the external code using path alias:

// https://example.com/ext-pkg/tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "~src/*": ["src/*"]
    }
}

// https://example.com/ext-pkg/index.ts
import foo from '~src/util/b'

from deno.

The thing that concerns me is that tsconfig.json doesn't work the same as package.json in that you can have a tsconfig.json in a totally different directory and use that one to compile project files, even if a tsconfig.json file exists in their own respective directories. As such, we can't assume that a tsconfig.json file in the same folder as foo.ts is actually the right tsconfig.json file.

from deno.

There's upcoming typescript features (3.0ish) to handle build "nested" typescript projects
microsoft/TypeScript#3469 (comment)
microsoft/TypeScript#21706 (comment)

from deno.

There is still some refactoring churn on the compiler. It is in the queue after that.

from deno.

@zheeeng if you're publishing a TypeScript library I think you would make sure not to use paths like that.

from deno.

I am going to take a look at this now. The compiler has settled down to a point where I think we can start to deal with this.

There are a few approaches that could be taken, and I am not sure which is best:

• We resolve tsconfig.json. If we do this, it will be a little bit problematic, as we will need not allow certain options to be passed to the compiler, as they would cause issues with how the compiler works. So there is a subset of options we can support and maybe even a smaller subset we want to support, so we can test them and make sure they work as expected.
• We create some sort of configuration file, which can operate in lieu of command line arguments and allow us to support the subset of TypeScript compiler options more cleanly. We could try to resolve this file by default at startup (e.g. ${cwd}/deno.json). This could be used for more complex configuration of Deno in the future as well.
• We create individual flags that we pass through to the TypeScript compiler that we would wish to support.

I would want to put the restriction that all modules will be transpiled with the same set of options for that programme. Adjusting it for each one is going to be problematic and confusing to the user.

My feeling at the moment of the only TypeScript compiler options we would want to support are:

So that is 6 options we can realistically support out of about 75 options that can be specified in the tsconfig.json (plus also files, excludes, includes which should have no impact on Deno). So I don't think supporting tsconfig.json would be very useful. Considering it is only 6 flags, and if we take out --locale and maybe --experimentalDecorators then that is only 4 flags we need, which makes adding them a bit more realistic.

Also, since we have a default behaviour of true for everything than --strict of the remaining 4, it might make sense to turn them to negatives, like --disallowJs, --noCheckJs, and --noResolveJsonModule.

@ry thoughts?

from deno.

Just an update on this issue: We are still heavily refactoring the core compilation infrastructure, so we're putting off adding stuff like that until it solidifies. In particular, we won't attempt address this until #975 is done.

from deno.

Sounds like a roadmap item? Perhaps we can discuss and formalize the requirements in this issue and add it to a milestone?

from deno.

On the surface, I think these are the problems or scenarios that need to be discussed for this issue:

1. If you require a file locally (e.g., import foo from './foo';) then it's probably a safe assumption that we don't need to track down a separate configuration; unless, like ESLint, we want to allow people to scatter different tsconfig.json files throughout their folder structure. This could be useful for testing purposes too.
2. If you require an external file (e.g., import bar from 'http://foo.com/bar.ts';), then this file could be using a separate configuration. The only thing I can imagine working is to look for http://foo.com/tsconfig.json.

Any thoughts on this or better ideas?

from deno.

@ry just so you know, I'm willing to help where I can. I'd love to contribute to this project.

from deno.

@jedmao Sure - I think the way to get started is to use this function and
https://github.com/Microsoft/TypeScript/blob/1b6d9229f2699b4285e32466818fa0abe925cd49/lib/typescript.d.ts#L3997
Maybe follow how TS-Node does it:
https://github.com/TypeStrong/ts-node/blob/70d68ef487e937c7d0ad4d6384fbe9b820ee51c9/src/index.ts#L462-L490

from deno.

Looks like findConfigFile maps to https://github.com/Microsoft/TypeScript/blob/b0f039c9e231638bb4d7c5588abbc7d8e7e4408c/src/compiler/program.ts#L4-L9

from deno.

@jedmao For not import module importer(e.g. require.js) in the browser env, developers often use Rollup/Webpack to bundle modules and provide a .d.ts declarations entry. The downstream lib could use the lib as js lib + .d.ts. These two pack tools all support path alias. Plz consider this usage and not force modification on them.

from deno.

@Bnaya I read that first lengthy post and I'm still not seeing anything that allows you to import a TS file and that TS file tells you where to find the tsconfig.json. Remember that you can have two separate tsconfig.json files that build the same TS file. The only solution I can think of is to put some kind of comment at the top of the TS file, but I'm not loving that idea.

from deno.

importing single ts file, without any metadata, is not a good idea imo.
you must have any manifest file, preferably in the package level

from deno.

@Bnaya, I agree. That's what I'm trying to figure out here in this thread. Do you have any suggestions that would work? Because currently, it looks like Deno will support single-file imports. I don't think the links you shared solve this problem.

from deno.

CC @kitsonk can you give an update on this issue?

from deno.

@kitsonk what is the status this issue?

from deno.