https://www.activepieces.com logo
Powered by
Howdy all, found the activepieces
# 🐶｜general
d
Howdy all, found the activepieces project while comparing several similar projects and have been trying to experiment with it to create/modify pieces locally and compose them into a workflow for prototyping purposes. I've had a bit of difficulty: - getting the repo to build from main following the developer docs: https://www.activepieces.com/docs/build-pieces/building-pieces/development-setup - understanding what functions and features of the software require an enterprise license for use locally I think the first point is largely a result of an active transition from 
nx
to 
turborepo
for builds? And the 2nd, it seems like all of the ce/ee code is sort of intermingled, and there are even several 
ee
folders that aren't? covered by the license? I'd like to minimize divergence between the main project and my fork, wondering if anyone has guidance on how I approach this?
Okay, yeah I was right about the migration problems. setup-dev is half bun, half pnpm/nx. I had some luck running this by using:
Copy code
json
    "predev": "node tools/scripts/install-bun.js",
    "dev": "turbo run serve --filter=web --filter=api --filter=@activepieces/engine",
    "dev:backend": "turbo run serve --filter=api --filter=@activepieces/engine",
    "dev:frontend": "turbo run serve --filter=web",
I'll also note, I was not a huge fan of seeing a repo script hook globally installling tools for me. I'd prefer bun was just called out in the readme as required. I already had it installed, but if I had not, I'd have been surprised to see it do that.
Side note, I just realized there is also a "building-pieces" channel, for my future interactions, which channels are most appropriate for development type discussions?
c
Thanks for the clarification. Atleast i know why it's failing now. I tried using your script. It kinda works (dev server starts) but on the browser, it just loads a spinner and I just get an empty screen and that error message in the terminal. Any ideas what might be going on here? Thanks for your help https://cdn.discordapp.com/attachments/1477330117578588335/1477517083586859211/Screenshot_from_2026-03-01_05-00-21.png?ex=69a50c83&is=69a3bb03&hm=d9e7d0f15d2f673a2b5bd57d1e6534e15cecbc0588841ffcab221033a62761d4& https://cdn.discordapp.com/attachments/1477330117578588335/1477517084014542879/Screenshot_from_2026-03-01_05-04-14.png?ex=69a50c83&is=69a3bb03&hm=e21f42ac3e0316c39841ccb6b903c035c2971007e7270e24079c0615f83c5671&
d
Give it a bit to start the server, it takes a long time
The frontend starts up instantly, and then it needs to wait around for the backend engine to slowly recompile all of the pieces before starting
Set your turborepo config to use tui mode so you can toggle between the processes with the arrow keys, it'll make it easier to debug each component separately
Also, I'm gonna say this repo/project seems like it's in rough shape. Feels like recent changes have been written on autopilot with a reduction in attention paid to architecture/API surfaces. 65k commits in under 3 years, more than one mostly-finished build packaging/build system migrations.
Hoping that the recent refactoring is a sign of good things to come, but the setup-dev script is a very good example of the problems. Within the same script: they run both bun install and pnpm install. The pnpm install fails because bun is set in the package.json.
Respectfully, and honestly: I am having trouble understanding how someone would make that mistake, if I'm replacing pnpm, I'm going to grep the repo for pnpm and make myself a todo list until they're all gone.
Even if I didn't test the developer setup scripts, it wouldn't happen
I'm going to do a bit more review of the code next week to decide how I feel about the piece APIs, and then I'll either move on or fork and repair the broken ce build. (Currently only the EE version builds)
For my own purposes, I don't really want/need a whole server platform. I just want a local prototyping and research agent environment. A bit like opal/breadboard-ai, but with: - less google-pilled AI integration APIs - better hot reloading support for iterating on components With my much smaller-scoped needs, this system is maybe a bit overkill.
m
Hi @Dan You are in the right track and i agree with most of things you have said Currently the team is overwhelmed and we are trying to focus on getting time to value fast (main focus the automation). We are open source and I am rooting for you 😄
d
Oh, hi @Mo, I think you're who I saw on the various commits trying to make progress swapping build systems 🙂 Out of curiosity, what's your background?
Also I hope you took my confusion/statements above as they were intended, reading it back I can see ways it could come off harsher than intended... I was truly expressing honest confusion and was/am attempting to deduce the current intent and pressures on the team.
m
The feedback was helpful and we are full aware of the situation 🫶🏻
I loved the tui trick!
d
Speaking on "we are open source" if I adopt activepieces for the mostly local prototyping/personal research agent use-cases I outlined above, what are your wants license-wise for my interaction with the ee code? I want to balance: - keeping my personal fork similar to upstream to contribute/receive patches - avoid accidentally re-licensing any code you intended to be ee code
Put real simple: I'm not launching a competitor, not tryna piss anyone off, and want to contribute back, can ya help me navigate this? ** @Mo feel free to DM me if that's an easier place to talk about this
2 Views
PreviousNext
Powered by