You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tip:ts-node differs slightly from tsc. It will not load files from tsconfig.json by default. Instead, ts-node starts from the input file and discovers the rest of the project tree through imports and references.
This is unfortunate for me. Essentially, I have a project where I can't add /// <references to the sources because the target (JS or WASM) is interchangeable, and the necessary declarations are added through extending different base tsconfig.jsons, relying on files being included.
Is there a way to force the old behavior in new versions of ts-node?
FWIW, no it should not be necessary to use files and, if it is, maybe you can share why it's necessary and someone can attempt to help you out with your configuration.
FWIW, no it should not be necessary to use files and, if it is, maybe you can share why it's necessary and someone can attempt to help you out with your configuration.
Thank you for your fast response. The project I was talking about is AssemblyScript, a TypeScript to WebAssembly compiler, where sources can be compiled to either WebAssembly with asc or JavaScript with tsc (and run with ts-node). Depending on the target, it is necessary to pull in different files via the files property within a target-specific tsconfig.json, but this property is ignored since ts-node 7. The reason why references within the sources cannot be used is because these would be invalid for the respective other target.
I did read the documentation, but wasn't able to spot a way to make ts-node honor the files property as it was before. Maybe you can point me in the right direction?
However, if a user of the compiler wants to run their own portable application with ts-node now, he has to do the same (plus one additional .js file) and cannot simply extend portable.json from within their tsconfig.json that used to set up everything without having to worry about any additional files.
Regarding types and references: One of the necessary additional files is a .js file that sets up the environment to mimic some things one would also have when compiling to WebAssembly. The definition file could be injected by other means I think, but the JS file is difficult. Any ideas?
Files is a boolean flag that, when enables, reads the files from configuration. It doesn’t accept a list of files. If that’s unclear in the README, can you let me know and I’ll try to improve it.
I don’t understand how you use the Javascript file - that was never how TypeScript or ts-node works - the additional files were for the compiler, not runtime.
Files is a boolean flag that, when enables, reads the files from configuration. It doesn’t accept a list of files. If that’s unclear in the README, can you let me know and I’ll try to improve it.
The documentation is actually clear on this. My mistake.
I don’t understand how you use the Javascript file - that was never how TypeScript or ts-node works - the additional files were for the compiler, not runtime.
Might well be that I am using some things in unintended ways, and it just so happened to work with ts-node 6 even though it wasn't intended. I guess I can live with --files being a flag, as you explained. Thank you for your time!
Activity
blakeembrey commentedon Jun 29, 2018
Yes, you can read the documentation or search existing issues. Tip: https://github.com/TypeStrong/ts-node#cli-and-programmatic-options.
FWIW, no it should not be necessary to use
filesand, if it is, maybe you can share why it's necessary and someone can attempt to help you out with your configuration.dcodeIO commentedon Jun 30, 2018
Thank you for your fast response. The project I was talking about is AssemblyScript, a TypeScript to WebAssembly compiler, where sources can be compiled to either WebAssembly with
ascor JavaScript withtsc(and run withts-node). Depending on the target, it is necessary to pull in different files via thefilesproperty within a target-specifictsconfig.json, but this property is ignored sincets-node7. The reason why references within the sources cannot be used is because these would be invalid for the respective other target.I did read the documentation, but wasn't able to spot a way to make
ts-nodehonor thefilesproperty as it was before. Maybe you can point me in the right direction?blakeembrey commentedon Jun 30, 2018
Couldn’t you use types or references to achieve this? Check the section on configuration, there’s a files flag.
blakeembrey commentedon Jun 30, 2018
Can you link me to some places I should look on how you’re expecting to use
ts-node?dcodeIO commentedon Jun 30, 2018
What I am doing for the compiler itself now is to use the files configuration setting explicitly with the duplicated array of files as you suggested.
However, if a user of the compiler wants to run their own portable application with
ts-nodenow, he has to do the same (plus one additional .js file) and cannot simply extend portable.json from within theirtsconfig.jsonthat used to set up everything without having to worry about any additional files.Regarding types and references: One of the necessary additional files is a .js file that sets up the environment to mimic some things one would also have when compiling to WebAssembly. The definition file could be injected by other means I think, but the JS file is difficult. Any ideas?
blakeembrey commentedon Jun 30, 2018
Files is a boolean flag that, when enables, reads the files from configuration. It doesn’t accept a list of files. If that’s unclear in the README, can you let me know and I’ll try to improve it.
I don’t understand how you use the Javascript file - that was never how TypeScript or
ts-nodeworks - the additional files were for the compiler, not runtime.dcodeIO commentedon Jul 1, 2018
The documentation is actually clear on this. My mistake.
Might well be that I am using some things in unintended ways, and it just so happened to work with
ts-node6 even though it wasn't intended. I guess I can live with--filesbeing a flag, as you explained. Thank you for your time!