Today I've split my monolithic stack into separate cluster + apps stacks (first step). If I understand it correctly, any common code (helper functions or component resource classes) need to go into separate package (typescript), otherwise importing a stack project into another stack project would result with creating the resources a second time. Anyway,

pulumi state move

command worked great, the biggest struggle I had was with my old resource structure. Thanks, Pulumi team!

You can have two projects import the same file, so long as it's not actually creating resources. If the common file defines a function that creates a resource, but that function is only called from index.ts or similar, then it'll be fine.

so project A has index.ts, where it creates resources (direcly or by importing other files), and in separate files some code - classes or functions. Project B can import those non-resource files directly? OK so I'd need to use direct imports to avoid importing the main index.ts, but I guess it should work. cheers

Yes don't import index.ts. And it's not recommended to have side effects of imports in general: importing a file should not cause a resource to be created (or anything to happen at all, ideally). Instead, export functions (maybe use the default export if you like that sort of thing) so that it's obvious to anyone reading the file that's doing the importing that something is happening. This is ok:

// file1.ts
import * as aws from '@pulumi/aws;
export default function bucket() {
  new aws.s3.Bucket('bucket');
}

// index.ts
import createBucket from  './file1';
createBucket();

This is not recommended:

// file1.ts
import * as aws from '@pulumi/aws;
new aws.s3.Bucket('bucket');
export {}

// index.ts
import  x from './file1';

I'm sure we're taking about the same thing, but let my just clarify. You do normally import index, every

import * as ${provider} from '@pulumi/${provider}'

imports the main index. Only in my case I also have a project that sets up resources. So I have two options: 1. I make a single base project for both resources and exported code. I can't use

import * as base from 'company-base'

since that would create the same resources the second time (first time in company-base project). 2. I make two projects, one for pulumi script that sets up the base resources, and another one for common functions and classes. This gives me the convenience of importing the index, just like with any other provider. The second option is cleaner. Another thing is splitting git repositories; so far I'm using a single monorepo (pnpm), while pulumi docs recommend keeping pulumi code with the apps. Adding outside dependencies is a more involved with either accessing private git repos (ensuring access for all users) or setting up a private npm repo, again with access for all.

You do normally import index, every import * as ${provider} from '@pulumi/${provider}' imports the main index.

Yes, for libraries this is the case. These are recognizable because index.ts is usually just a pile of exports. For index.ts files with side effects (e.g.: create resources), you shouldn't do this. Don't import a Pulumi project: do import a library that provides Pulumi component resources, and functions that create resources.

I call it project if it has package.Json. it's simply a node library project, not pulumi project

Ah, then yes, that's where the misunderstanding happened.