Monorepo support

[tim-evans]

Hi there! This library is ❤️ soooo lovely ❤️

We've started making our library from a single TypeScript repo into a multi-repo project (a la glimmer). We'd love to use libkit for this so we don't have to duplicate our build steps across our packages.

Some of the things that would be nice for us:

• A single build file 🎉
• A way to install all dependencies from the root of the project
• A way to publish new versions of all sub packages using the CLI
• Appending the License to the beginning of compiled output would also be lovely if we choose to open source this.

Thanks again, awesome people 🥇

[chancancode]

Appending the License to the beginning of compiled output would also be lovely if we choose to open source this.

It sounds like you want to compile down to a single file, something like ember.{min,prod}.js, is that correct?

Our general philosophy for libraries is:

• we think people should distribute loose modules:
  • JS modules without the TypeScript annotations) plus .d.ts files (for JS applications).
  • TS modules (for TS applications)
• we think applications that use the libraries should use a bundler like Webpack, Rollup (or Ember CLI, patch pending) to pull in the loose modules and compile them using a single tool. This allows a single tool to apply optimizations across the high-level codebase (the ES6 imports and exports, as well as other semantically rich information like arrows and class definitions).
  • This prevents semantic bugs in earlier versions of transpilers from forever plaguing users. It also allows users to use target and preset-env across all of the libraries they're importing, rather than being stuck with tough decisions a library author made that may not apply to them.

We don't have a problem with adding support for producing a single-file modules as output (and might even implement it ourselves), but we think that, when possible, people should try to use loose modules as inputs into a compilation step, rather than pulling in precompiled bundles.

That being said, do you have any preference for what the output of a single-file build should look like? Named AMD/UMD modules? Browserify? Global variable? All of the above? Orthogonally, should we roll-up private internal modules?

(We admit that we don't always implement this philosophy in a perfectly coherent manner, but would like to eliminate inconsistencies with this philosophy where possible and would take patches to that effect.)

-- Yehuda & Godfrey

[tim-evans]

We're close to the libraries, yes. We would like to export a series of modules that developers opt into.

A specific example that may highlight our needs best is our integration work with frontend libraries.

We have a bunch of modules that express accepted input formats and output formats. We would like to provide developers to pick only what's needed for them. For example, if they have a document in Markdown that they would like to render in React, we would like them to be able to import the following modules:

• @atjson/commonmark-parser
• @atjson/react
• @atjson/core

To get what they need. We also have other modules, which may be completely unnecessary for their needs, such as:

• @atjson/commonmark
• @atjson/glimmer

And so on. Since some of our modules have large dependencies, we would like to have them pick and choose.

The consumers of our library would all use build systems (most are babel + webpack), so we're fine with anything that would interop well with their toolchain.

We find that lerna bootstrap; lerna run build; lerna run test; lerna publish works fine, but is a bit cumbersome for our development process. It also doesn't support ember server across the packages very nicely, which makes testing annoying.

-- @tim-evans & @blaine

[wycats]

@tim-evans We added yarn workspace support quite a while ago. I'm gonna go ahead and close this issue. If you have any additional monorepo goals, please open a new issue and I'll take a look.

[tim-evans]

Hi @wycats thanks for the heads up; I should've closed this since we've since changed to using tsc and lerna directly.