Do not emit json file with config flag "resolveJsonModule" = true

[sevenryze]

Expected Behaviour

Emit json files when we set this tsconfig flag "resolveJsonModule" to be true.

Actual Behaviour

There is no any json file emitted.

Steps to Reproduce the Problem

Given the folder structure:

src/
    index.ts  <--- this file `import package from "../package.json"`
package.json
webpack.config.js

The webpack config like below:

entry: {
    "src/index": path.join(__dirname, "src/index.ts")
  },
output: {
    path: path.join(__dirname, "dist"),
},
loader: "ts-loader" with no other options.

and tsconfig.json like below:

{
  "compilerOptions": {
    "module": "commonjs", 
    "moduleResolution": "node",
    "target": "esnext",
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "sourceMap": true,
    "resolveJsonModule": true,
    "declaration": true,
    "declarationMap": true,
    "removeComments": true,
    "strict": true,
    "alwaysStrict": true
  },

  "include": ["src"]
}

After invoke webpack, I only get the dist/src/index.js file, not the dist/package.json file.

Location of a Minimal Repository that Demonstrates the Issue.

[johnnyreilly]

Surprising; I thought this would be resolved by
#793

[sevenryze]

currently i don't know why that happens, but i will dig some in code for resolving this issue after my vocation, that's not hard for me. this issue is a preplace mark for others who might have the problem.

[johnnyreilly]

Thanks - that would be awesome!

[sevenryze]

Sorry for late replay, i just got my laptop after my vocation a little while.

I think the issue #793 was merely able to let the resolveJsonModule flag to be passed without errors, but not actually emit the json files, which you could check by re-initializing the minimal repo from that issue and list the assets of the compiler.

What i found could be summarized to two points:

1. we should provide additional files like .json to webpack as same as declaration files. For that, we could add one more test clause to deal with json files. A temp workaround is change constants.dtsDtsxOrDtsDtsxMapRegex to constants.dtsDtsxOrDtsDtsxMapRegex || constants.jsonRegex in here:
   

   ts-loader/src/after-compile.ts

   Line 264 in 5490e9d

   outputFile.name.match(constants.dtsDtsxOrDtsDtsxMapRegex)

2. we should find a way to deal with the typescript wired(maybe i'm wrong with something)? behavior, that is the program will not emit the json files when providing the targetSourceFile to program.emit, and do emit json files when replacing targetSourceFile to undefined. Ref code:

   ts-loader/src/instances.ts

   Line 310 in 5490e9d

   program.emit(

The tsc comment said:

/**
* Emits the JavaScript and declaration files. If targetSourceFile is not specified, then
* the JavaScript and declaration files will be produced for all the files in this program.
* If targetSourceFile is specified, then only the JavaScript and declaration for that
* specific file will be generated.
*
* If writeFile is not specified then the writeFile callback from the compiler host will be
* used for writing the JavaScript and declaration files. Otherwise, the writeFile parameter
* will be invoked when writing the JavaScript and declaration files.
*/
Though, according this comment, we should get all related files produced(including json and declaration files), this behavior is not properly function for our case currently.

If we use my temp workaround for point 2: replacing sourceFile to undefined, other issue raised as we need to process output js and map files for multi-entry project.

Could you help me to figure out how to fix the point 2? i find the tsc source code has been not structure pretty since i check it 1 year ago, and you must be more familiar than me. 😄

PS:
I made a tiny pure tsc project and found the tsc using https://github.com/Microsoft/TypeScript/blob/29dd67ec40361db26612a86aa6bb52ca5e7f34a8/src/compiler/watch.ts#L131
to compile my project. I don't know if it's useful for you...

[johnnyreilly]

Question: if you const someJson = require('./someJson.json') what is the behaviour? Does webpack emit json in this scenario? I'm just curious as this so post suggests it should work and it shouldn't be different from the import....

https://stackoverflow.com/questions/49996456/importing-json-file-in-typescript

[sevenryze]

Oh, i'm sorry for forgetting mention my custom scenario.

I make a custom workflow for my backend nodejs dev that i don't use webpack module resolve feature for some modules. in case that, i need the ts-loader to emit declaration and json files the same as we using tsc from cli. (behavior aligned)

So, according your question, i guess this is intentional for ts-loader to omit json and rely on webpack own json processing?

and if my guess is right, is my custom scenario useful for others? should we add a flag to opt in this feature for using ts-loader to emit json files?

[johnnyreilly]

Okay... So you're using webpack to build the backend, but you want the json files to be loaded at runtime; not made into a module that webpack requires? i.e. you don't want the json to be built into the build output and it is right now.

Sorry, I don't think I've been completely understanding your use case up until now.

Is that right?

[sevenryze]

yah, you are right. that's exactly what i want.

[johnnyreilly]

I see. So to summarize, the behaviour you want to support is:

When using webpack to build nodejs, have the ability for webpack to not package a something.json file, instead emitting a require('./something.json') statement and likewise emitting the something.json file in the webpack build output?

Is that accurate?

[sevenryze]

Yes, that is my request, you get my point.

i think if we don't use webpack own module parsing function, we need at least to support the same function as plain tsc, like emitting json and declaration files. so, we could leverage the outDir and declarationDir flags of tsc to control where to output assets other than .js and .js.map files.

But, i don't know if this feature is too special or too custom to merge into mainline?

[johnnyreilly]

Cool - I'm glad I understand you.

But, i don't know if this feature is too special or too custom to merge into mainline?

Possibly. But it depends. It's worth saying that ts-loader supports vuejs but in an indirect way. Essentially we added support for being able to suffix .ts to files so we could pass them on to the TypeScript compiler:

https://github.com/TypeStrong/ts-loader/blob/master/README.md#appendtsxsuffixto-regexp-default

The addition of this was minimal to the ts-loader codebase (it didn't add a ton of complexity) and didn't introduce any dependency upon Vue and the behaviour was "opt-in"; i.e. a custom option.

If you're able to support your scenario and meet roughly the same criteria, we might merge it. That said, because your use case seems particularly custom I'm not certain it's a great idea.

Let me explain why:

If you're loading the json at runtime then you open up the possibility that the json loaded might not actually be the json built with.

Let me put it another way: what's the advantage of not including the json in the built output? As far as I can tell, there's no scope here for alternative json being loaded at runtime (as you might do if you were supporting localisation). So what's the benefit of this suggested approach?

I'm sure you have one in mind but I don't follow it right now I'm afraid!

[sevenryze]

First, thanks for your patience! 👍

Then, as you can realize, in backend devs, we always hit the point that there are lots of dynamic generated assets, which can not be including in the output in advance. So, for processing this assets, including the json files generated by compiler and packer, consistantly, using our own post process tools, we need the feature mentioned upon.

As ts-loader is one of the best ts loader of webpack, i think it's good to make this feature as an option for guys like me.

For now, i will modify my own custom ts-loader for testing and experiment purpose, after that, i'll re-open an issue and we could discuss this feature further more and i'll list all the benefits i could collect.

Thanks again, for your help. 😄

[johnnyreilly]

First, thanks for your patience! 👍

No problem!

As ts-loader is one of the best ts loader of webpack, i think it's good to make this feature as an option for guys like me.
For now, i will modify my own custom ts-loader for testing and experiment purpose, after that, i'll re-open an issue and we could discuss this feature further more and i'll list all the benefits i could collect

That sounds like a great idea. I always find it easier to talk about an idea based upon an initial implementation rather than in the abstract.

Feel free to open a speculative PR when you want to talk about this further and link back to this issue. Don't worry about having fully passing tests before you do that; just open the PR and we can use that as a basis for collaboration and discussion.

Best of luck!