How to use shared components in multiple apps without addon

Ember CLI
1

Hi, we have a four apps that share a lot of components. So far we use addons to manage this shared code, but we’re facing a lot of troubles with addons approach.

Something like this:

App1
- basic-form-elements-addon
- feedback-form-addon
- tables-management-addon
App2
- feedback-form-addon
- tables-management-addon
App3
- basic-form-elements-addon
App4
- basic-form-elements-addon
- tables-management-addon

The problem with this approach is that updating an addon is a quite long process involving a lot of steps:

  1. Link addon into app (using yarn link)
  2. Modify addon code
  3. Publish addon into npm
  4. Update dependency in App1
  5. (and possibly if I have a time and energy, update dependency and usage in App2,3,4 as well or leave it for someone else who touches that code :cry:)

Apart from this, there are other problems

  • maintaining 8 different ember apps costs a lot of time
  • updating ember versions
  • updating other dependencies
  • maintaining same linting configs and other tooling

these are the biggest issues we face now with this approach.

I don’t know what’s the best solution to this problem, but my idea was that we would

  • merge all addons into one addon (now that it’s possible to require just part of the ember tree, it shouldn’t have a bad impact of a code size, right?)
  • move all code into one repository (kind of monorepo)
  • use addon not as npm dependency, but somehow import it from the sibling directory (I don’t know if this is possible)

so at the end, we would end up with something like this

git (monorepo)
- App1
- App2
- App3
- App4
- shared-code
--- components
--- helpers
--- models
--- ...

Is that possible? What would I need to do to achieve this setup? Or do you have a better solution?

Thank you for any kind of help, Ondrej

2

We are facing a similar issue. @ondrejsevcik did you find a solution? What would be the “state-of-the-art” solution for this problem?

3

We’re using yarn workspaces. It helps a lot with a publishing and linking nightmare.

4

@ondrejsevcik I also had a look on yarn workspaces could you elaborate a little bit more how you set things up? Did you follow just the blog post of square or did you do something else?

My problem was a little bit different and so the solution of square didn’t fit my case 100%

5

No, nothing special, we just moved all the apps and addons into one workspace.

How exactly is your use case different?

6

We had a Glimmer.js app inside of our mono-repo and we wanted to re-use some TypeScript utility classes, something like feature-detection etc

git (mono-repo)
- glimmer-ui
- utils
- some other TS project

Then we imported from the utils folder like this:

// other TS project
import FeatureDetector from '../utils/feature-detector';

But in the Glimmer project, the same import does not work. So I tried to set it up with yarn workspaces but I didn’t manage it to work and had not enough time to play around a lot.

It would be awesome if it would be possible to just import stuff from anywhere and do not have to setup some npm/yarn shenanigans

7

You should be able to import that stuff the same way you did when it was living in a separate package. Yarn workspace is just a convenient way to do automatically “yarn link” on all of your own repositories that lives inside that workspace.

8

Yeah I think our problem was some combination with TypeScript etc. When we use relative imports the TS file is compiled and bundled. If we import from node_modules the file was not compiled and only bundled by Rollup. Since we didn’t pre-compile our TypeScript utility class we weren’t able to get everything running.

Would be nice if ember-cli could just follow all imports. The problem is, that everything under the root of the ember project is mirrored to a tmp folder. Everything which is above the root of the ember project is therefore not visible during build.