Add a monorepo option?

[bitjson]

Add a monorepo option?

[cspotcode]

Can't you just setup your normal lerna project, then cd packages, then npx typescript-starter? What am I missing?

[joemphilips]

FYI. I was trying to use this starter in my monorepo and bumped into some troubles along the way.
the biggest problem was that git treated the library as a submodule, which sometimes behaves nasty.(It took me some time before I discovered CI was failing because the CI service won’t pull the contents in submodule.)

Anyway, my current workflow for using this library in monorepo is

1. run npx typescript-starter my-sub-package out side of my monorepo.
2. run lerna import --flatten to treat the package as a sub-package in monorepo.
3. tweek package.json for my-sub-package and add cross-env CI=1 before running ava (otherwise ava might fail to pipe stdout to lerna when I run something like lerna run test --stream)
4. delete .circleci/ and .github/
5. change tsconfig.json to extend root level tsconfig.json (mostly for importing internal dependency using baseUrl and paths, you don't need this if it has no internal dependency)
6. if it is going to be scoped package, do the following

• change name in package.json to scoped stile (e.g. @my-namespace/my-sub-package)
• add "publishConfig": {"access": "public"} to package.json

7. delete ”config”: “commitizen” from package.json and remove commitizen from devDependency

• since I use commitizen with cz-lerna-changelog in the root level

8. delete version script and standard-version

• since this conflicts with lerna publish. (It tries to run git tag more than twice and throws an error)

Hope this will help someone.

[josephmcasey]

I would love to help contribute this feature! Do the project maintainers feel like this issue appropriately identifies all of the feature requirements before I create a pull request?

[chadbr]

You might look at how google structures it's nodejs client libs:

https://github.com/GoogleCloudPlatform/google-cloud-node

I'm planning to reproduce a similar structure based on this project

[bitjson]

@Alxandr thanks for opening an issue!

I'm not really sure if this repo is the right place for demonstrating a monorepo project structure, but I'd be very open to reviewing a pull request for it. Right now the project is a single node module – did you have an idea of what else / how you'd like it to look as a monorepo?

(Also, thanks – I might need to consider Lerna for the project that inspired this starter.)

[Alxandr]

No, well, if you ask me a monorepo should be the default nowdays. I originally did development primarily in .NET, and the fact that I have to create multiple repos in node is one of the big pain-points IMHO. Without having looked into it too much, I would guess that mainly you would have to move src into packages/<module-name>/src and create a new package.json at that point, and mark the outer package.json as private and only contain dev-dependencies there.

[bitjson]

Now that typescript-starter has a CLI, @cspotcode's method seems like the best way to do this.

There may be a way for this project to help a little more though, so I'll leave this open for now. Feedback/comments appreciated.

[bitjson]

That’d be great! PRs for this are definitely welcome. I don’t really have anything to add other than that it should be optional (so this project can still be used for non-monorepos). Otherwise, feel free to make it work how you want it to work 😄

Let me know if you have any trouble! (I’m happy to help with the tests.)

[josephmcasey]

Hey @bitjson

I looked over this project last weekend to provide a solution for this feature request. I have some questions after working on this project for the first time.

Testing was a little difficult due to manually updating snapshots. Is there a simple way to update the snapshot / hash tests quickly?

My primary point of discussion though is something I didn't expect which was that the project using most of its file contents for building the starter template (rather clever actually). It seems like the cleanest solution here is either segregating the files that are used for building the starter template and the files that are used by the project cli scripts. Another solution could involve moving the project to a mono-repository structure and using the same multi-use concept to support both a mono and multi repo starter template. Let me know your thoughts when you have a moment.

[bitjson]

Hey @josephmcasey, thanks for working on it!

While you're developing, you might want to just disable those snapshot tests – they serve to verify that a contributor has confirmed the CLI's output to be correct in each of the configurations. We can wait to update them until the new feature is ready to merge. (And then adding snapshots to confirm that the feature is working gives us a very strong guarantee that simple things like dependency updates don't change the output of the CLI.)

Once you're ready to update the hashes, you can confirm the the build is what you expected, then just copy the hash which the test expected and replace the old one for each modified file. It's a manual process because reviewing the output of each file is also a manual process.

I don't have a strong opinion yet on the best way to go about this. I would also be open to separating the CLI files more from the project files – this was just a simple and expedient way of getting things working.

Have your seen TypeScript 3's new project references? I imagine the best solution for this includes using that feature.