Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question/Feature Request] Specify different tsconfigs for different instances. #926

Closed
ozyman42 opened this issue Apr 25, 2019 · 5 comments

Comments

@ozyman42
Copy link

ozyman42 commented Apr 25, 2019

We can specify different instances of ts-loader like this:

module: {
        rules: [
            // this will fail if both files are passed through the same instance
            { test: /a\.ts$/, loader: '../../index.js' },
            { test: /b\.ts$/, loader: '../../index.js', options: { instance: 'different' } }
        ]
}

but is there a way that I can have each of these instances use a different tsconfig? Perhaps one set of files is allowed to have dom related types and another set of files is meant to be universal and so should not have any dom types.

In my use case files from both sets need to end up in the final 1 bundle.

@andrewbranch
Copy link
Contributor

andrewbranch commented May 19, 2019

You can use the configFile option: https://github.com/TypeStrong/ts-loader/blob/master/README.md#configfile-string-defaulttsconfigjson

Perhaps one set of files is allowed to have dom related types and another set of files is meant to be universal and so should not have any dom types.

But you actually don't want two different ts-loader instances. You really want project references. Project references don't work great with ts-loader right now, but they will soon.

@ozyman42
Copy link
Author

Extending my example such that there is a universal set of files, a web set, and a node set, will project reference support (once it's done), bundle the built universal js into both the node and web bundles?

@andrewbranch
Copy link
Contributor

Project references itself doesn't bundle anything—that's webpack's job. You'd have two root projects: node and web, each of which reference a third project: the shared code. Running tsc -b on the node project will build both the node project and the shared code. Where the output goes depends on the outDir of each of those projects. Running webpack on the web project will also build the shared code, emitting output to its outDir but then also piping that JS into the rest of webpack's build system, meaning you'll get a bundle with the web code and the shared code that can be shipped to a browser.

@ozyman42
Copy link
Author

Makes sense. So then if I use webpack for both the node and web sets, I would get 2 bundles, both containing copies of the transpiled shared code.

@andrewbranch
Copy link
Contributor

Yeah, I guess so. I wasn’t thinking about using Webpack for node, but yeah, that would work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants