Allow emitDeclaration and isolatedModules together

[SimenB]

Search Terms

isolated modules emit declaration

Suggestion

In the blog post introducing Babel 7, it's recommended to use --isolatedModules in the "Caveats" section (https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/).

We use Babel to transpile our TS to better work with other tools in the ecosystem (such as Emotion or Jest), but we'd also still like to generate declaration files so consumers of our libraries can enjoy the type information.

However, when trying to follow the advice of adding isolatedModules to our config, we get the following warning:

tsconfig.json:5:5 - error TS5053: Option 'declaration' cannot be specified with option 'isolatedModules'.

5     "declaration": true,
      ~~~~~~~~~~~~~

Use Cases

As mentioned, I'd like to create declaration files for libraries who are transpiled using babel. I'd also like to make sure that whatever guarantees isolatedModules adds to allowed syntax are present, outside of the type information.

Babel itself will complain if we use e.g. const enum, but that only happens at compile time - isolatedModules will also show a warning in the IDE while writing the code.

Examples

Same as we currently get with {"declaration": true, "emitDeclarationOnly": true}, but with added {"isolatedModules": true}.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[dlannoye]

I am also looking for something similar. I will be using babel as a compiler via webpack for a monorepo, but still want features like project references for the editor experience in my monorepo and generating d.ts files for packages that are published.

For my situation having a way to enforce the same limitations on language features that aren't supported by isolated modules without the restrictions on other typescript features would be ideal. I think that just means having an alternative way of treating usage of const enum, namespace, and re-exporting types by name as errors.

[mheiber]

Why does this restriction currently exist?
Related StackOverflow question asking about the restriction: https://stackoverflow.com/questions/49403410/why-declaration-can-not-be-used-together-with-isolatedmodules-in-typescript

[DanielRosenwasser]

Everyone in the room is currently trying to figure out why this is a restriction. 😅

[mheiber]

It looks like the restriction was there since the branch for separate-compilation (now isolatedModules) was first merged into master.

The restriction was added (I think) in response to feedback which pointed out that declaration: true makes no sense for transpile (now transpileModule).

Maybe the same restrictions need not apply for isolatedModules and transpileModule, since allowing emit of declaration files makes sense for the former but not the latter.

[mheiber]

@RyanCavanaugh @SimenB proposed above allowing emitDeclaration and isolatedModules together. This issue is marked Needs Proposal.

What else is required in order for this to be a full-fledged proposal?

[weswigham]

FYI, for anyone still reading this: The reason is for the same reason you can't use const enums in isolated modules: type information. Since isolated modules compiles each file individually without the types of the files it depends on, any inferred type we would write to a declaration file would potentially be incorrect, as their calculation would be missing information from the rest of the compilation. There is a limited subset of declaration emit where no types are inferred in the output which could be supported, however.

[mheiber]

Thanks Wesley! I understand now.

What's recommended way for a user of babel-typescript to also generate declaration files? Something like the following?

• Have a main tsconfig used for building and checking
• Have another tsconfig for declarations that extends the first tsconfig and has the following overrides: {"isolatedModules": false, "emitDeclarationOnly": true}

@SimenB would that meet your needs as well?

[SimenB]

I'd have to run tsc twice? Would that bust the cache of tsconfig.tsbuildinfo?

[weswigham]

I'd have to run tsc twice? Would that bust the cache of tsconfig.tsbuildinfo?

You should be able to specify a separate tsbuildinfo path for each build so they don't mangle one another's incremental data.

[mheiber]

@weswigham it doesn't seem like specifying the a separate tsbuildinfo path may not be necessary

I'm seeing that the name of the tsconfig is automatically used as part of the name of the tsbuildinfo file.

Given these tsconfigs:

tsconfig.json

{
    "compilerOptions": {
        "incremental": true,
        "isolatedModules": true
    }
}

tsconfig-for-declarations.json

{
    "extends": "./tsconfig",
    "compilerOptions": {
        "emitDeclarationOnly": true,
        "isolatedModules": false,
        "declaration": true
    }
}

When I run both tsc and tsc -p tsconfig-for-declarations.json I see two separate buildinfo files on disk:

• tsconfig-for-declarations.buildinfo
• tsconfig.buildinfo

tested on Version 3.4.0-dev.20190320

[mheiber]

@weswigham , you said:

There is a limited subset of declaration emit where no types are inferred in the output which could be supported, however.

Would this be the same limited subset that applies to TS files? If so, it seems like the restrictions would be worth it. Would implementing this change be a big effort or a small tweak? I know some people who may be interested in implementing.

[mheiber]

@weswigham checking in on this issue again.

We'd really like to get the extra checks from --isolatedModules while also generating declaration files. Doing an extra pass would really slow down our pipeline.

Is more information needed? Some question here. Thanks for your help with this issue.

[mheiber]

Pinging about this again.
We'd be willing to make this change if it's of manageable size.

[DanielRosenwasser]

@sheetalkamat is this small enough? Is it a matter of just disabling the check?

[DanielRosenwasser]

P.S. I'm going to assign you but if the issue is scoped enough, I'm going to encourage @mheiber to send a PR.

[mheiber]

@sheetalkamat , do you have guidance for us re:

• level of effort needed for this fix
• level of expertise needed for this fix

If both are low/medium, we might be able to find someone who can contribute a fix.

Thanks for your help.

[sheetalkamat]

@mheiber @DanielRosenwasser and myself had discussion offline and it seems like the use case of what should be emitted in d.ts file is kind of vague. We are waiting on @RyanCavanaugh to be back to discuss this further to understand what .d.ts emit means, do we need to put some kind of restriction (eg specifying all types and nothing can be inferred) is still unclear. We also need to decide on what builder needs to do depending on outcome of .d.ts emit.

I am removing help wanted label from this as we are yet to come to conclusion on desired behavior.

mean while we would like to know why do you need to use isolatedModules is it for faster .js emit which checks only that file? What about --incremental flag with requiring you to compile only subset of files with each change.

[mheiber]

@sheetalkamat thanks for looking into this and asking about our use cases.

We're using isolatedModules because we want to be able to do separate compilation with ts.transpileModule in our Gulp pipeline. We use isolatedModules to verify that separate compilation is safe. Here are some of the specific reasons:

• simpler
  • we can remove our dependency on the massive amount of plumbing between Gulp and the TS compiler API that is in gulp-typescript.
• fast incremental builds and fast initial builds.

We are excited to take advantage of your work on incremental compilation, but can't use it yet because (as far as I know) the TS compiler API does not yet offer incremental compilation

• memory usage: we're currently stalling our entire pipeline so that all the files in our build are synchronously available for the TS compiler API.
• performance in general: we are considering running the checker in a separate process, or making type-checking optional
• compatibility with all TS tooling:
  • we may use babel-plugin-typescript in future, which does separate compilation (and therefore needs to be checked with --isolatedModules).

cc @robpalme: I think Rob may have more thoughts on why we're interested in --isolatedModules.

[mheiber]

thanks @sheetalkamat and team!