-
Notifications
You must be signed in to change notification settings - Fork 102
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
Parsing tsconfig.json with support for extra commas #48
Comments
I know why.because my tsconfig.json uses jsonc. But, tsc support jsonc. It would be better to have tsconfig-paths support jsonc.
|
Yes that makes sense. To put this in some context, first we used the tsconfig package to do parsing of tsconfig.json. Then we needed to support the So given the above, I guess what is missing is support for extra commas, I would be happy to take a PR for adding this support (while still keeping the extends and comments support that already exists). |
ts-node -r tsconfig-paths/register.js
can not work
It looks like I haven't tried it yet, but |
IIRC tsconfig-paths currently strips comments and then uses plain JSON.parse(). It would indeed be interesting to know what tsc uses internally to parse tsconfig.json. |
I think json5 is the most popular choice if we should go with an external library. There seems to be a function called UPDATE: Found another function called |
@jonaskello make it a peerDependency? If someone is using tsconfig-paths, there's a very good (if not guaranteed?) chance s/he is already using typescript. |
@jshado1 I was thinking the same thing at first. However some ppl use tsconfig-paths in production with something like |
I think the arguments from babel/register (babel/babel#5851) apply here: The register should not be used in production: It should be pre-compiled, which is actually how I'm trying to use it, paired with |
Yes, I would tend to agree with that and I do not use it in production myself or recommend it. Still I think it would be better to have a small dependency so we keep our options open. From my research JSON5 seems like the most popular option so I think we should simply switch to use that instead of the built-in Anyway, if someone would like to provide a PR to change to JSON5 that would be accepted :-). |
Specifically I think this line needs to use JSON5. |
* Switch from JSON.parse to JSON5.parse resolves dividab#48
@jonaskello done 🙂 |
* Add support for comments and trailing commas * Switch from JSON.parse to JSON5.parse resolves #48 * add ts typings for json5
By the way, @jonaskello how do you yourself handle this in production? Is |
I mostly do monorepos with yarn workspaces. There is a nice example of how to do it here. Notice how paths in tsconfig are used in development but not in production, as stated towards the end in that repos readme. Usually I have client, server, and shared package in the monorepo, sometimes more packages in order to split things more nicely. The client side is handled by using webpack with tsconfig-paths-webpack-plugin so the paths are resolved while bundling. For the server side normal npm package resolving works once all packages has been built (and yarn install is used on the workspace root so all my packages are symlinked under the common node_modules). If you want to resolve the paths statically, I noticed there is the tspath package. If I understand the readme correctly it replaces the paths statically after building but I have not tried it. |
Thanks! I was hoping to avoid adding a huge dependence like webpack for only 1 tiny feature. I saw tspaths—the readme sounds exactly like what I want. Unfortunately, it seems to nbe broken :( |
If you really want static path resolving I guess it should not be too hard to do a package that does that. AFAIK tsc does not have a plugin system yet so you would have to compile with tsc first and then replace the paths in the resulting js files. The way I would do it would be to use the typescript or babel-parser package to parse the js files into an AST, and look for any |
Did some more research and it seems like you could also achieve static path replacement by writing a plugin to ttypescript. That would probably be the simplest and most integrated way available today. |
package.json
run command
ts-node -r tsconfig-paths/register.js test.ts
I really use the command
cross-env TS_NODE_PROJECT=./tool/tsconfig.json && ts-node -r tsconfig-paths/register ./node_modules/webpack/bin/webpack.js --config ./tool/config.webpack.dev.ts
cross-env TS_NODE_PROJECT=./tool/tsconfig.json && node -r tsconfig-paths/register webpack --config ./tool/config.webpack.dev.ts
I don't know how to use it.
The text was updated successfully, but these errors were encountered: