Skip to content
This repository has been archived by the owner on Aug 6, 2023. It is now read-only.

Think about planck again #17

Closed
artemyarulin opened this issue Jul 22, 2016 · 5 comments
Closed

Think about planck again #17

artemyarulin opened this issue Jul 22, 2016 · 5 comments

Comments

@artemyarulin
Copy link
Owner

artemyarulin commented Jul 22, 2016

So, we have many ugly reg-exp, which is not a problem by itself - it works quiet stable. But here the list of bigger problems:

  • Fighwheel requires to have main in the project file. Specifying it manually for each library requires to much extra work, but without it we have no REPL
  • We have custom ./build.sh repl [target] command which we heavily use in order to open NREPL connection. It's outside of this repo, while with Clojure it's essential thing to have. And the implementation with Clojure is straight forward, while with ClojureScript we have additional watchman/rsync madness
  • Even with ./build.sh repl it still requires to much thinking what target to choose, as currently we have like ~5 targets per library?
  • With buck exec we can add more cool commands to targets - generate docs, release to clojars, etc.
  • Too many targets created for each module
  • Customisation of project.clj
  • Add test-deps property - it quiet usual case that we want to have additional modules for test
  • Sometimes we need to define multiple test runners - node|browser|rn or jvm. Can we unify it as well?
  • By default we only test with :whitespace optimisations. How user can check that module works with advanced optimisations as well?
  • Consider case: I have a module which works on node, tests passes. I've added it as a dependency to the module which is browser only. As we don't copy the tests from the dependencies we may not notice such mistake
  • Consider extracting task like clj_dep so that modules would use always modules functionality. This way we'll able to lock external dependencies versions. Although it would make releasing open source projects much harder

So, what we can do - unify things by using buck executables and handle all parsing with planck

@artemyarulin artemyarulin changed the title Think about plank again Think about planck again Jul 22, 2016
artemyarulin pushed a commit that referenced this issue Jul 22, 2016
Current version is still broken as figwheel requires to have main specified in the compiler settings. We cannot provide it without too much hassle from the developer. It's actually bigger issue handled here #17
artemyarulin pushed a commit that referenced this issue Jul 22, 2016
Current version is still broken as figwheel requires to have main specified in the compiler settings. We cannot provide it without too much hassle from the developer. It's actually bigger issue handled here #17
@artemyarulin
Copy link
Owner Author

Here some rough ideas of how it may looks at the end

clj_module('a')  # a.clj   (ns example.a)
cljc_module('c') # c.cljc  (ns example.c)

cljc_module(name = 'b',
            src = ['b.clj','bb.cljc'],
            tests = 'b_test.cljc',
            deps = [':a',':c','//ext/promesa-0.4.6'],
            depsTests = '//ext/koh.test-0.1.0',
            runners = ['node','browser','rnative','my-own'],
            main = 'lib.b')

# Some additional executables that we may provide
clojars_release(modules = ':b',
                name = 'koh.b',
                version = '0.1.2-SNAPSHOT') 

extract_public(title='B is all about B',
               docModules = [':b'],
               licence = 'MIT')

# Following target would be created:         
""""
# source only targets, for working with dependencies
//lib/a:a
//lib/c:c
//lib/b:b

# repl executables, starts repl with Clojure project if clj_module, ClojureScript otherwise
//lib/a:repl
//lib/c:repl
//lib/b:repl 

# meta target, depends on actual tests for each platform
//lib/b:test 

# actual test targets, so we can run it separately if we want
//lib/b:test-node
//lib/b:test-browser
//lib/b:test-jvm
//lib/b:test-rnative
//lib/b:test-my-own
"""

@artemyarulin
Copy link
Owner Author

artemyarulin commented Jul 22, 2016

Couple of things to notice:

  • No separate build targets - build in this case just a sanity check and for checks we have tests which will build a module in any case. It doesn't make sense to have build on their own - if we want to be sure that module is in a correct state, well then add a test. LIKE IT VERY MUCH
  • Runners - for sure we should include node and browser runners as a default, but I guess rnative could be to much custom and it will be used as our own

Question: How can we customise node with additional libs that module may need? Making own runner is too much for such usual thing. And in general - how can we customise runners? I want rnative for iOS only for example and so on

@artemyarulin
Copy link
Owner Author

artemyarulin commented Jul 22, 2016

Answer:

runners = {'node': {'modules': ['xmldom']}
           'browser':{},
           'rnative':{},
           'my-own':{'a' True}}

@artemyarulin
Copy link
Owner Author

Answering one of the questions from the top: If module has a custom main attribute then probably it's mean to be used as a end product so we would add release task which would run tests twice: with whitespace and advanced optimisations to be sure we've covered everything.

So actual targets would be:

//lib/a:a
//lib/c:c
//lib/b:b
//lib/b:b-release

//lib/a:repl
//lib/c:repl
//lib/b:repl 

//lib/b:test
//lib/b:test-release

//lib/b:test-browser
//lib/b:test-browser-release
//lib/b:test-jvm
//lib/b:test-jvm-release
//lib/b:test-my-own
//lib/b:test-my-own-release
//lib/b:test-node
//lib/b:test-node-release
//lib/b:test-rnative
//lib/b:test-rnative-release

@artemyarulin
Copy link
Owner Author

Closed via 063daab

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

No branches or pull requests

1 participant