Kk/config export #45
Kk/config export #45
Conversation
krzkaczor
commented
Nov 26, 2018
krzkaczor
commented
- move config
- fix package manifest & build
|
Really nice 👍 |
|
@krzkaczor Really really great! Didn't expect to have ALL this set of config files included! 😄 👍 I would like to do a short brainstorming round, if having these dependency here on the local I would also like to give other active contributors the chance to have a look: Please take the chance and have a look, also on the associated PR of the new config repo coming along with this ethereumjs/ethereumjs-config#1. |
|
@whymarrh trying to provide module paths was the first thing that I tried. Something like "ethereumjs-config/typescript/tslint.json" this, unfortunately, doesn't work without specifying main file in the package (which we can't do because we would need to specify multiple different entrpoints, tslint config, nyc config etc). So basically I don't see any other way to accomplish it :( |
|
@krzkaczor Can't we use a proxy |
|
@holgerd77 interesting idea. I doubt that it will work but i will check it out :D |
I think this is a case for separate packages. It doesn't make sense to have unrelated configurations deployed in the same way. I think they can all live in the same repo and be published as individual npm packages (e.g. |
|
Would this be a use case for this lerna tool? Stumbled upon that along with all the monorepo discussions, hehe. 😄 Seems to be lightweight enough to also cover simple use cases (like this one), where e.g. no bootstrapping (linking) between dependencies is needed. If this generally fit this would also be some occasion to generally get in touch with that and collect some experiences (nevertheless @GrandSchtroumpf, no no, no new general monorepo discussion for the moment 😄 😄 😄). |
|
hahah yes exactly it sounds like monorepo for config. I know that you love it @holgerd77 😆 I can switch to that approach. I think it will solve all of these issues. |
|
Ok, but without the smiles 😄 do you think it makes sense and is a good fit for this use case (and not e.g. overblown/overengineered)? Then let's do it. |
|
@holgerd77 yup I was thinking exactly about that. As a side note: I created my first monorepo with TS and it's not that great. Tooling sucks (VSCode doesn't navigate between the files correctly, you need to watch files constantly and rebuild type info). So I wouldn't push for it if it doesnt make sense here. |
|
Any way to also centralize the lint, format, test (other?) related Also thought about moving the dev dependencies to global installation, but this is unrealistic due to in-real-life very like iteratively updated packages on configuration, using different versions at some point in time. |
|
Ah, the explore command is then also running in the scope of the dependency (which probably should have been expected), just tested Nevermind, was just an idea, if someone has some brilliant concept on this please speak out 😄, otherwise we should stick to getting the current scope done. |
|
@holgerd77 i never heard about doing anything like that :( |
|
Just created a new Phew, but still have to do a do a google session on every line of code change, but probably that's the way things go. 😄 |
|
Down to 2 errors for the main Would be cool if you guys could have a first look. Not sure if I can really avoid But maybe I am also just missing something and there is an easier way to achieve this here. Not sure, eventually we can also stay on the strict side. With the current structure it is possible to override settings, or isn't it? So for libraries where things get to complicated we could then decide case by case. Anyhow, really great, I am still delighted how much I enjoyed this so far! 🕺 😄 |
|
(and already side-caught 3-4 errors along the way) |
| "outDir": "./dist" | ||
| }, | ||
| "include": ["src/**/*.ts"] | ||
| } |
There was a problem hiding this comment.
Ah yes, thanks, missed that one in my review.
|
Checked back, all change requests from @whymarrh are resolved, will dismiss his review. |
