https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# typescript
s
This message was deleted.
w
Thats a cool project (live-plugin-manager). Interested to see if you can pull this off. Is it not as simple as this?:
Copy code
import {PluginManager} from "live-plugin-manager";

const manager = new PluginManager();

async function run(packageName = "my-pulumi-project", componentName = 'MyPulumiResource', id = slugify(`${packageName}-${componentName}-main`), args = {}, options = {}) {
  await manager.install(packageName);
  const { [componentName]: TargetComponentResource } = manager.require(packageName);

  const resource = new TargetComponentResource(id, args, options);

  return { resource };
}

run();
p
Hmmm lemme check
Yeah right now i have similiar code to load in a componentresource. Right now the problem im facing is that.
The component resource that is on remote (github) exists in a Pulumi project directory folder
w
Oh. So when you load the module, you get a bunch of other Pulumi resources created that you don’t want?
p
That basically means whenever i inject/download the remote component resource it gets injected locally and attached to the remote project
I basically want the possibility to create a Pulumi project myself because right now i have like 10-15 stacks of the remote github project
w
Can you require it from a subpath?
Copy code
pathToComponentFile = '/src/my-component';
...
const { [componentName]: TargetComponentResource } = manager.require(packageName + pathToComponentFile);
p
Oooh wait thats a good one actually
Charley do you perhaps also know if you can create a pulumi project through the automation API?
i only saw the possibility to create stacks
w
Or can you change the source project to have two entrypoints: 1 for the pulumi project and 1 for the library?
You can create pulumi projects via the automation API
“Projects” might be referred to as “workspaces”
p
Hmm brb 1m imma grab my laptop haha
w
^ I think that is all that is needed to both create the stack and the project.
I could be wrong.
p
yeah but
wait you are maybe right hahaha
i made the assumption that the third parameter requires a inprocess Pulumi program, but since im injecting the component resource through live-plugin-manager it might work aswell
imma try it out rn
w
Yeah, honestly, I can’t see why it wouldn’t work unless there is something about the way Pulumi executes programs that involves weird serialization, but I don’t think so. The weird serialization I’ve seen with Pulumi is when I’ve accidentally used objects that have circular references to create args within the program (now I just pre-serialize the objects into DTOs and all is well)
p
i have a question btw
this is the third parameter in the git example u posted
Copy code
import {PluginManager} from "live-plugin-manager";

const manager = new PluginManager();

async function run(packageName = "my-pulumi-project", componentName = 'MyPulumiResource', id = slugify(`${packageName}-${componentName}-main`), args = {}, options = {}) {
  await manager.install(packageName);
  const { [componentName]: TargetComponentResource } = manager.require(packageName);

  const resource = new TargetComponentResource(id, args, options);

  return { resource };
}

run();
should the return resource of the run function be the value of the program parameter?
w
program
?
p
yeeah
w
program: () => run()
, is how i’d do it
I think
p
kay lemme try
w
TS might want you to make it 
async
too:
Copy code
program: async () => run(),
Copy code
program: async () => await run(),
^ Both would be valid I think
p
ah it seems not working yet, tomorrow i will try on and will keep you updated
Error side seems to be from the plugin manager rn
error: Unhandled exception: Error: Cannot find module
one question
why did you wrap brackets around the return value 
return { resource };
w
I just wrote it like that because whatever you return are your stack outputs, and it is just easier for me personally to know what the keys are instead of making them dynamic. So by writing 
return { resource }
I can always expect to look at the stack’s 
resource
key to get the outputs for the component. Had I written 
return resource
, the stack’s outputs would become dynamic and dependent on whatever outputs 
resource
happens to have. All this said, there might be some property on ComponentResource that contains the actual outputs instead of the full resource object, like maybe: 
resource.outputs
so in either case I’d write:
Copy code
return resource.outputs
return { resource: resource.outputs }
But I don’t know if there a convention for outputs for ComponentResource or exactly how Pulumi handles stack outputs, as I rarely use/consume stack outputs.
p
Ok im sorry, im having trouble following your advice so i made a very very basic example of it. I’ve been troubleshooting it for 2x3 hours and i still get errors. Do anybody mind helping me out? My client where i try to live inject a remote npm repo: https://github.com/dnhook123/pulumi-live-injection the npm/ git repo im pulling: https://github.com/dnhook123/pulumi-cr-platform The error im getting: TypeError: process.on is not a function at /Users/david/WebstormProjects/pulumi-live-injection/plugin_packages/@pulumi/s3/s3Mixins.ts1905 at /Users/david/WebstormProjects/pulumi-live-injection/plugin_packages/@pulumi/aws/s3/s3Mixins.js1215 at Script.runInContext (nodevm139:12) To reproduce download the client and run the following command in root directory 
npm install
npm start
w
@pulumi/s3
is not a package I am familiar with. I’m sorry, the process.on thing is not something I’ve ever seen. Anyone else?
7 Views
Open in Slack
PreviousNext
Powered by