Support baseUrl/path import aliases (and other newish ts/ts-node features) #8787
Comments
mikhailshilkov
added
area/sdks
|
Overlaps with #3061 |
|
Hello @tenwit ! Coming across this issue just now, and I wanted to give a little more context into how I'm currently thinking about this issue and its blockers. I'm reading this issue as having two main feature requests (plus documentation):
TL;DR: IMO these three items are separate requests. I also think these items are tracked in other open issues. This is really exciting for me, because it indicates that these are features people really want, if users are independently arriving at the same conclusions. I'm going to type up an explanation of the state of the world for the features as described above. More Flexible Dependencies
This one has been on my radar for six months now, and I really want to improve things here. 馃 The short answer is "no, that's currently a breaking change, but I wish it weren't so!". The long answer is under discussion here. I'm hopeful we can come up with a slick solution. For example:
Another approach that's rattled around in my mind, but I don't have a good design for, is some kind of "lifecycle hooks" for the Node runtime. A lot of the motivation for upgrading TS-Node and TypeScript versions is using one's own typechecker or transpiler for faster builds. I'd like to consider adding a configuration option to the TypeScript runtime that allows users to specify their own build step. For example, putting this in your runtime:
name: nodejs
options:
typescript: true
buildStep: build...where Better Monorepo Support
RE: path mapping, I recently used path mapping in our generated Node code, but I came across this open bug in the TypeScript compiler which makes path mapping unusable in libraries. I suppose that as long as your Pulumi program as I expect once #2619 is closed, you'll be able to use path mapping without issue. Does that sound right to you? Pass Args to Runtimes
Right now, the Pulumi engine executes a Go binary called the "language host", which is responsible for spinning up each "language runtime" and providing the runtime with the appropriate flags. The good news is that way flags are passed between the $ cargo run -- custom args --and -subcommands=trueThe bad news is that this requires plumbing into all six of our language runtimes: NodeJS, Go, Python, Dotnet, YAML, and Java. That makes a little daunting of a task for one person, but because it's parallelizable and support for each language can be implemented in isolation of the others, maybe it's something we can collaborate on with a community contributor. If I understand your ask correctly, this issue is tracked in #10122, #2619, and #3061. Would it be fair to close this issue as a duplicate of those? I'm happy to continue the conversation here or in those issues. I'm actively working on #2619 , passively working on #10122, and unfortunately #3061 is backlogged for now. |
|
EDIT - I am using pulumi version 3.33.2 @RobbieMcKinstry So I'm currently trying to figure out an issue around the following :
I have a monorepo setup with NX, but we don't use one central tsconfig/package.json file. We have a tsconfig file defined in the root, and then in our pulumi directories we extend our base tsconfig file. I'm having trouble making use of path mapping in my pulumi program. When I'm in the code, Typescript/ESLint seems to be happy with my path mapping reference ( My repo setup is : And my tsconfig.base.json file has : My Pulumi project has the following tsconfig : I've attempted moving the path mapping for |
|
would love to see support for paths |
|
Removed the
#2619 has been closed, but this is indeed still an issue. Using {
"compilerOptions": {
"strict": true,
"outDir": "bin",
"target": "es2016",
"module": "commonjs",
"moduleResolution": "node",
"sourceMap": true,
"experimentalDecorators": true,
"pretty": true,
"noFallthroughCasesInSwitch": true,
"noImplicitReturns": true,
"forceConsistentCasingInFileNames": true,
"baseUrl": "../",
"paths": {
"myapp": [
"app"
]
}
},
"files": [
"index.ts"
]
}The current workaround (via #3061) seems to be to use {
"compilerOptions": {
"strict": true,
"outDir": "bin",
"target": "es2016",
"module": "commonjs",
"moduleResolution": "node",
"sourceMap": true,
"experimentalDecorators": true,
"pretty": true,
"noFallthroughCasesInSwitch": true,
"noImplicitReturns": true,
"forceConsistentCasingInFileNames": true,
// 馃憞馃憞馃憞
"baseUrl": "../",
"paths": {
"my-alias": [
"./my-local-path"
]
}
},
"files": [
"index.ts"
],
// 馃憞馃憞馃憞
"ts-node": {
"require": ["tsconfig-paths/register"]
}
}...or adding a block to the TypeScript program entrypoint (e.g., import * as tsConfigPaths from "tsconfig-paths";
const config = tsConfigPaths.loadConfig("./");
if (config.resultType === "success") {
tsConfigPaths.register({
baseUrl: config.absoluteBaseUrl,
paths: config.paths,
});
}
// ... the rest of your index.ts. |
Hello!
Issue details
Some of my typescript Pulumi codebases are monorepos, and suffer from relative path hell. Typescript provides the path mapping sugar to help with this.
I'd also like to use ESM throughout my codebases. ts-node supports this, though currently only via experimental settings.
Recent changes in Pulumi seem to allow supporting these features much simpler (e.g. pulumi/templates#244, #8655), though it might not be possible yet (#4876).
Requests:
Affected area/feature
Typescript support.
The text was updated successfully, but these errors were encountered: