Skip to content
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

Question/Feature Request: How to replace the build step? #247

Open
svallory opened this issue Mar 11, 2024 · 6 comments
Open

Question/Feature Request: How to replace the build step? #247

svallory opened this issue Mar 11, 2024 · 6 comments

Comments

@svallory
Copy link

Hi there!

I want to replace the compilation step and do something similar to what tshy so I can rely on running tsc and have more control of the compilation.

Since tshy does some of the work that packemon does, I was thinking of simply having a script to build each dialect. The script is simple and does the following:

  • creates a tempory package.json in src with appropriate module
  • symilnks the package root to src/node_modules/[PKG] to support imports
  • compiles tsconfig.DIALECT.json
  • deletes package.json and src/node_modules

How hard would it be to customize packemon to call a script or a function I'm exporting to do that?

@milesj
Copy link
Owner

milesj commented Mar 11, 2024

The build process is very tightly coupled into packemon, especially around folder structure, and how exports are mapped. I don't have plans to change this, as packemon is meant to be used as-is, since it does all the heavy lifting.

You're probably better off forking packemon if you want this kind of custom functionality.

@svallory
Copy link
Author

svallory commented Mar 11, 2024

The build process is very tightly coupled into packemon, especially around folder structure, and how exports are mapped. I don't have plans to change this, as packemon is meant to be used as-is, since it does all the heavy lifting.

You're probably better off forking packemon if you want this kind of custom functionality.

I understand. Since packemon optionally supports swc I thought this could fall into that category.

I don't mind forking to customize, but before doing that, I would like to know if there's anything else that packemon depends on besides the folder structure. I mean something from babel or rollup.

In other words, my idea was that I would replace only the transpilation phase, ensuring the folder structure is exactly what packemon expects. Would that be enough? What are other possible pitfalls?

@milesj
Copy link
Owner

milesj commented Mar 11, 2024

Packemon only supports swc, as it's a drop-in replacement for babel, both of which get fed into rollup. Both babel and rollup have custom plugins to achieve certain functionality.

In other words, my idea was that I would replace only the transpilation phase, ensuring the folder structure is exactly what packemon expects. Would that be enough? What are other possible pitfalls?

This should be enough off the top of my head. Would need to dig through everything in Package and Artifact files to verify.

@svallory
Copy link
Author

Got it! I'll take a look and see if it's too much trouble or not.

@svallory
Copy link
Author

svallory commented Mar 11, 2024

Oh, btw @milesj, are you interested in taking a look at the solution (in case I decide to implement it) to see if a PR makes sense?

Or is that something you don't want to support due to the added complexity?

@milesj
Copy link
Owner

milesj commented Mar 12, 2024

Yeah, depends on the complexity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants