polylith 2021-07-05 | Slack Archive

Is polylith ready for purely clojurescript projects?

The tool currently only recognises .clj and .cljc source code files. But there is nothing stopping you from organising your frontend code in a Polylith way, which I know that e.g. @U2BDZ9JG3 has done in some of his previous projects, but without tooling support.

furkan3ayraktar06:07:14

The nature and needs of the frontend projects are different than the backend. Especially, development experience in most of the frontend projects are pretty good. We did not have much experience to judge how Polylith would fit into that environment, so we did not work on supporting ClojureScript projects at the moment. However, I tend to keep the Polylith like project structure and exposing functionality with interface named namespaces. In any case it is a good practice to have clear separation between different parts of the codebase. I would recommend doing the same.

cyppan09:07:36

I have introduced a new “schema” component in our Polylith project, which has a beop.schema namespace prefix, but it makes the poly check fail, because of every code that imports the prismatic lib with require [schema.core ...] Error 101: Illegal dependency on namespace schema.core in data-api.config. Use schema.interface instead to fix the problem. Does it mean that all the polylith components named like <vendor>.<name>.* shouldn’t be used along libraries named like <name>.* ?

cyppan12:07:28

I have tried to rename the components/schema folder to components/beop-schema and the checker still doesn’t like (same error), I don’t understand how it detects usage :thinking_face:

cyppan12:07:06

I’ve packaged the minimal code to reproduce here https://github.com/cyppan/polylith-bug-check

seancorfield16:07:08

@U0CL38MU1 Is this using poly master or issue-66 branch?

cyppan16:07:56

it’s master

seancorfield16:07:15

Let me try your repo against the issue-66 branch...

cyppan16:07:08

I guess I’ll have to migrate at some point anyway 🙂

seancorfield16:07:04

I just tested against the latest issue-66 version and it works fine:

(! 504)-> clojure -Sforce -M:poly info
  stable since: 2e956be

  projects: 1   interfaces: 1
  bases:    1   components: 1

  project        alias  status   dev
  ----------------------------   ---
  development *  dev     x--     x--

  interface  brick    dev
  -----------------   ---
  schema     schema   x--
  -          api *    x--
(! 505)-> clojure -Sforce -M:poly check
OK

but you do have to make some changes: add workspace.edn and add deps.edn to each base and component.

seancorfield16:07:32

(! 506)-> cat workspace.edn 
{:vcs {:name "git" :auto-add false}
 :top-namespace "me.cyppan"
 :interface-ns "interface"
 :default-profile-name "default"
 :compact-views #{}
 :release-tag-pattern "v[0-9]*"
 :stable-tag-pattern "stable-*"
 :projects {"development"       {:alias "dev"}}}
(! 507)-> cat bases/api/deps.edn 
{:paths ["src"]
 :deps {prismatic/schema    {:mvn/version "1.1.12"}}}
(! 508)-> cat components/schema/deps.edn 
{:paths ["src"]
 :deps {}}

(that's just very roughly put together -- and :auto-add is normally true by default)

cyppan17:07:41

ok thank you I’ll have a deeper look into the issue-66 branch then

tengstrand17:07:54

It looks like you @U0CL38MU1 have found a bug in the main branch, because I could reproduce it in main but not in issue-66. In the issue-66 branch you also normally put deps.edn files per component, where you specify its dependencies + that the polylith key should be removed from the root deps.edn. The tag patterns are stored like this: :tag-patterns {:stable "stable-*", :release "v[0-9]*"} in workspace.edn. You can get inspiration from the Polylith repository itself by looking in the https://github.com/polyfy/polylith/tree/issue-66 branch if you don’t have time to wait for the migration too that I’m working on (+ some minor fixes).

cyppan17:07:26

Thanks for the investigation, a migration tool would be great 👍 as a temporary fix I’ve renamed my component

👍 2

2021-07-05

Channels