Support multiple entry points about ts-loader HOT 10 CLOSED

Does each entry point get its own instance of the TS language service? I think the answer is yes.

If they resolve to the same configuration, why?

Can each entry point specify it's own tsconfig, and if so how?

Interesting, I'm not sure when you could need that. I've been using the Webpack context to resolve the tsconfig.json, but previous I resolved based on the entry file location. It kind of won't work here though and I'm not sure how you would expect two to work - each file could be compile using two different styles from different import locations and I think it'll break.

Can each entry point specify its own loader options, and if so how?

As above.

from ts-loader.

If they resolve to the same configuration, why?

Globals, I think. If they shared an instance any ambient declarations would be available for both which might not actually be the case at runtime. Also there's the case where they don't share the same configuration 😄 but, as you said...

Interesting, I'm not sure when you could need that

I'm not entirely sure either, but my gut is that "it could happen". Take the following case:

• project
  • intranet
    • tsconfig.json
    • app.ts
  • public
    • tsconfig.json
    • app.ts

For sure it's conceivable that the tsconfig.json files could contain different files (for different .d.ts files, for instance, see the "globals" argument). As for compiler options I'm having a harder time coming up with a solid use-case for that. It's conceivable they could have different targets maybe if they know they support ES6 somewhere.

resolved based on the entry file location

This is how ts-loader works right now.

BTW, this got on my list because we do something very similar at AssureSign. We have multiple independent "apps" that share a common webpack config but not tsconfig. Right now our build process just runs webpack over and over again changing the entrypoint, but it would be nice if we could just use multiple entrypoints instead and I wasn't quite sure if/how that would work.

from ts-loader.

BTW, this got on my list because we do something very similar at AssureSign. We have multiple independent "apps" that share a common webpack config but not tsconfig. Right now our build process just runs webpack over and over again changing the entrypoint, but it would be nice if we could just use multiple entrypoints instead and I wasn't quite sure if/how that would work.

We have a similar setup where I am. That is to say a single webpack config and a number of "apps" (in reality compartmentalised pieces of functionality that make up part of a larger app). Each of these apps has a single tsconfig.json. It all works rather well; so well I've never really thought any more about this.

to share the relevant bit of our wepack.config.js:

entry: {
    secondaries: './src/angular/secondaries/main.ts',
    companyQuarterly: './src/angular/companyQuarterly/main.ts',

    // common dependencies bundled together packaged with CommonsChunkPlugin in gulp/webpack.js
    angularVendor: [
      'babel-polyfill',
      'angular',
      'angular-animate',
      'angular-sanitize',
      'angular-ui-bootstrap',
      'angular-ui-router'
    ]
  },

secondaries and companyQuarterly are both "apps". angularVendor is a shared bundle.

All of which is a very long way of saying: ts-loader seems to support this already. At least for my own use cases.

Can each entry point specify it's own tsconfig, and if so how?

I have a shared tsconfig.json. That's worked out fine for me so far. I guess it'd be nice to be a little more isolated; but honestly I haven't been burned by the current setup at all.

Can each entry point specify its own loader options, and if so how?

Again I'm not sure I'd ever use this. I can't think of a situation which would demand it.

from ts-loader.

Actually, ts-loader does not support this fully. It sometimes works, sometimes it doesn't. I also use two entry points, each for a separate client app that has its own .tsconfig inside. The two are dependencies of the main module that holds the webpack config:

entry: { studio: require.resolve("studio-client"), learn: require.resolve("learn-client") }

The problem arises when you have different modules inside of them. It sometimes happens that it doesn't read both projects .d.ts files before trying to compile, so it throws a lot of "unknown module" errors for one of the entry points. Sometimes, it works. Not sure what's happening there, but I'm guessing that separate instances of ts service would fix that.

from ts-loader.

I have two entries: browser and service worker. Each have their own folder with a tsconfig.json. This is necessary because the browser and service worker envs need different libs.

When I try to use ts-loader with this setup, it seems that one tsconfig.json is being used for both entry points, so I get many errors like:

ERROR in ./src/client/main.ts
(11,21): error TS2304: Cannot find name 'window'.

ERROR in ./src/client/main.ts
(70,15): error TS2339: Property 'serviceWorker' does not exist on type 'WorkerNavigator'.

ERROR in ./src/client/main.ts
(77,47): error TS2339: Property 'serviceWorker' does not exist on type 'WorkerNavigator'.

ERROR in ./src/client/main.ts
(86,15): error TS7006: Parameter 'permission' implicitly has an 'any' type.

If I run tsc with the tsconfig.json directly, I get no error messages.

from ts-loader.

@OliverJAsh last time I checked, ts-loader didn't support multiple tsc instances, not sure if anything changed. I switched to at-loader because of that a year ago, and used the instance and include properties, like this:

{
  test: /\.tsx?$/,
  include: "./path/to/entry/index.ts",
  use: [
    {
      loader: "awesome-typescript-loader",
      options: {
        instance: "myInstanceName",
        configFileName: "./path/to/entry/tsconfig.json"
      }
    },
    "angular-router-loader",
    "angular2-template-loader"
  ]
}

You need to do this twice, once for each of your entry points. It runs a separate instance of tsc for each entry point.

from ts-loader.

@dbettini the instance property is in ts-loader as well. Looks like @OliverJAsh got it working here: #647

from ts-loader.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from ts-loader.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from ts-loader.

Closing as stale. Please reopen if you'd like to work on this further.

from ts-loader.