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

New build system #30

Open
diegomura opened this issue Aug 2, 2018 · 4 comments
Open

New build system #30

diegomura opened this issue Aug 2, 2018 · 4 comments

Comments

@diegomura
Copy link
Collaborator

@devongovett We introduced lerna to be able to inject different module implementation into textkit core, which I think it's great. It give us great flexibility, specially if we want foliojs projects to run everywhere (textkit itself and other libs still has node dependencies that, even if shimmed, people may want to avoid).

But working with it I experience a lot of pain: publishing many packages in cascade, complex project layout, etc.

That's why I thought about switching into a new approach (exactly what nextjs does):

  • On build, create each module entry separately using rollup into a dist folder, including our current core module. Each module will have an entry js file at the root of the project (as nextjs does)
  • That would enable to require each module separately from textkit/core, textkit/linebreaker, etc. No more packages folder. We can have the whole code base together. Also, no more scoped package names
  • Export a default setup, so you can just require textkit and have a working solution. This internally will import the core and bind all default modules.
  • Alternatively, you can import textkit/core and the specific subset of textkit modules (or own modules) and create your custom TextLayout as you currently can

I'm very convinced we should do this. Would love to hear your thoughts!

@devongovett
Copy link
Member

Doesn't lerna automatically bump the versions when publishing?

@diegomura
Copy link
Collaborator Author

Supposedly yes. But I recall having issues working with it. No exactly what since it’s been awhile I don’t publish. But still I think there has some other benefits

@devongovett
Copy link
Member

https://lernajs.io/#command-publish - says it will publish anything that changed.

So, if I understand you correctly, instead of separate npm packages, you would like to publish one package with subfolders. Correct? I think the general tradeoff here is whether the packages are tightly coupled together in the first place. if the sub-packages are tightly coupled, then you'll need to install everything anyway. If the packages are usable independently, then it is nice to only install that package without the rest of them.

@diegomura
Copy link
Collaborator Author

says it will publish anything that changed.

Yes. It's not that with Lerna I cannot achieve what I want (I do). It's more about not shipping textkit in +10 different packages, which IMO makes things a bit more akward both fo mantainers and users

if the sub-packages are tightly coupled, then you'll need to install everything anyway. If the packages are usable independently, then it is nice to only install that package without the rest of them.

Packages are made in a way that they are not tightly coupled together, which I think its nice. Installing everything it's not much concerning because even though you will download it, if you don't use a particular module you won't ship it in the final build.

Maybe I put much emphasis in Lerna, which is not my main concern. I was thinking more in not having to install more than 6 packages when you want to do a custom text layout. I worked with next extensively lately and I really enjoyed how it's shipped, so I thought proposing it. And if there's a time to do these types of changes is now that there are no reported people using textkit (rather than me haha).

Having said that, I'm more than ok of just keeping things how they are

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