Repository navigation
Please remove the following code (v0.9+) #135
Description
The shouldIgnore() function found here https://github.com/TypeStrong/ts-node/blob/v0.9.0/src/index.ts#L302 prevents anyone from storing any .ts or .tsx files in node_modules directory.
function shouldIgnore (filename: string) {
return relative(cwd, filename).split(sep).indexOf('node_modules') > -1
}
function registerExtension (ext: string) {
const old = oldHandlers[ext] || oldHandlers['.js'] || require.extensions['.js']
oldHandlers[ext] = require.extensions[ext]
require.extensions[ext] = function (m: any, filename: string) {
if (shouldIgnore(filename)) {
return old(m, filename)
}
return loader(m, filename)
}
}This will force them to stick to v0.8 of ts-node or shift their support elsewhere.
I think this code is unnecessary. If I require / import a .ts file then I obviously want it to be compiled. Otherwise I will get a JavaScript syntax error. I see no scenario where someone would try to include a TypeScript file and not want it compiled. A better algorithm would be to let ts-node/register simply try to compile every .ts and .tsx file it comes across and only choose when it comes accross some other file like .js.
Activity
blakeembrey commentedon Jun 14, 2016
I don't think so. You should never be publishing modules as
.ts. I would prefer to allow you to override the ignore function, but I don't think that particular practice should be promoted.Edit: Not to mention, you don't know that you're requiring a
.tsfile if the extension is obscured. If you really wanted a module to be TypeScript and not JavaScript, you could dorequire('ts-node/register')within the code itself effectively sandboxing. I don't think either way is pretty though (and the register may not work today, I'll fix it if it's not). If you are publishing modules please don't publish them in TypeScript.wotsyula commentedon Jun 14, 2016
.tsfiles and you'll implement it?node_moduleshave to come from npm.org. I totally agree with your statement. But sometimes I put my own private repos there. Helps me organize my code.npm install path/to/gitornpm install path/to/folder. This helps me to build websites faster not to mention anything innode_modulesdoes not require../../../which you will see a lot in bigger libraries..jsfiles, I lose debugging info :'-( I'm sure they'll fix it but in the mean time I'd like this to work.Tell me what you think and how I can help.
blakeembrey commentedon Jun 14, 2016
I think maybe if it supports a
--ignoreoption which would override the default check. It could probably be a glob string, or a regexp pattern, whichever seems more reasonable. Then when you use that, you'll be in control.wotsyula commentedon Jun 14, 2016
Ok. But I kinda hate configuration. Leads to more bugs and code thats difficult to modify down the line. Any way to do this without adding any extra if / else statements or config values? Maybe
ts-node/registerAll. Then even if we changed the configuration down the line it won't cause such a fuss. I know this would mean adding another file to the project. But in it instead of callingregister(even more opts)it could callregisterAll().blakeembrey commentedon Jun 14, 2016
Internally it would still need to be an ignore option.
blakeembrey commentedon Jun 14, 2016
I don't think it's any more complexity really. If it's implemented so the default is
node_modules/**it looks the same, but allows you to override it when needed.wotsyula commentedon Jun 14, 2016
hmmmm. Guess its up to you to decide then. My vote is to switch back to the old sys rather than add a new config or keep things as they are. Was this changed due to increase performance? Just want to know.
blakeembrey commentedon Jun 15, 2016
Nope, no performance reason. I just didn't account for people relying on the
node_modulesbehaviour, it was never particularly a feature, just a side-effect. No one should be using raw TypeScript as a module, it's a horrible practice to enable that leads to bugs and fragmentation.huan commentedon Jul 30, 2016
I vote for permit load ts module in node_modules directory. because typescript should be super set of javascript, so should be modules. ;-)
felixfbecker commentedon Sep 14, 2018
The problem with
--ignoreis that it is cumbersome to supply when using ts-node with Gulp. You always have to runTS_NODE_IGNORE='[]' gulp foo.I agree that shipping TS is not a good idea for the common use cases and especially libraries. But I have a use case where a repo is just a small extension of a big second repo, and needs to pull in 90% of its code, including things like webpack config, gulp tasks etc. Simply depending on the source was the best option considering all factors and alternatives.
It would be great if this could somehow be inferred from tsconfig.json - maybe don't ignore
node_modulesif I explicitly list it ininclude?blakeembrey commentedon Sep 15, 2018
@felixfbecker This would lead into a larger discussion, since compiling modules in
node_modulesmay be using a different configuration to your current configuration. The other option is thatts-nodeonly compiles files specified intsconfig.jsonalways? Would that help your use-case or hinder it at all?blakeembrey commentedon Sep 15, 2018
One big issue with following
tsconfig.jsononly though, and I'm not sure how this relates with new features such asreferences, is in the early days (and probably still today for some people) code would be compiled by specifyingfilesonly and spider out from the entry point.ts-nodeworks the same way, I'll have to think about how I can make this all play together first-class. Do you have any thoughts on how to make this work better? Maybe ignore this edge case and move the current behaviour under a "catch-all" flag, then maketsconfig.jsonthe default. We could then supportreferencesby creating multiple compiler instances that each followtsconfig.json.