@teambit/application - breaking changes affecting applications

[TGTGamer]

Description

Just had a bad experience with the Teambit components.

Looks like one of the components was update (import { AppContext } from '@teambit/application') which broke my build pipeline because the latest version of bit was being installed on the new pipeline.

This new build of bit kept erroring on something I couldn't replicate locally because it wasn't using the version of the @teambit/application that my devices were using.

I know this change is a few months old, but believe I should say something as breaking changes like these, should be avoided, and could have been avoided.

https://github.com/teambit/bit/blame/906585e86d19dcd183f632cb1e13291cd5376cdb/scopes/harmony/application/app-context.ts#L98

I have a fork of harmony-platform which I maintain because I needed access to the private generateAppRoot funnction, so that I could change the entrypoint generation. That fork is what broke, and the Bit maintained repository was only updated last week with the fix:

      context.hostRootDir,
      context.port,
+      undefined,
      context.workspaceComponentPath,
-      envVariables
+      context.envVariables
    )
  }
}

https://bit.cloud/bitdev/harmony/harmony-platform/~compare?version=2.0.9&file=harmony-platform-context.ts

Specifications

upgraded from version 1.8.48
current is now linked to version 1.9.56
Specifically it looks like the issue was introduced in version v1.9.44 v1.8.127

Context and additional information

#9216

fe3a458

[Jinjiang]

@TGTGamer I feel really sorry about that. It do broke things and should be avoided.

As you mentioned, it was months ago. I think reverting it back is also challenging at this moment. And the corresponding code upon it like the harmony platform should be adapted as well. However, we can discuss further if there is a particular case that we can't deal with it. I'd be open on it due to the situation.

Apologize again. 🙏

[TGTGamer]

@Jinjiang I'm not sure what the best solution to this issue is long-term, might just be stricter internal checks and nothing changing outside that.

I believe I am one of few who are maintaining / utilising forks of teambit components (harmony in my case), therefore I'm directly dependant on some of the "internal" modules. This was the main reason I opened the conversation, to open the discussion about how we can do better, including how maybe we could change harmony and other components to be more customisable, removing this "forking" problem entirely. E.g. using "protected" instead of "private" for extendibility of classes, allowing functions to be overwritten by users like myself if we choose to.

[Jinjiang]

Totally understood.

I think we can try to improve the experience and process from more than these points below:

1. we do our best to avoid breaking changes in the future
2. just in case we have to make some big change, we will ensure to bump up the major version of the component we are going to change
   • technically in this case, there could be another way to improve it, which is introducing a new static helper method like AppContext.create({ ...options }) or AppContext.from({ ...options }). this approach can: 1) avoid break existing APIs, 2) the options is a key-value pairs object which doesn't have an arguments order issue. I'm right now trying to improve some part of our source code in this way
3. once anyone forks a component, or anyhow directly relies on an API looking "internal", or just curious about the usage of any APIs, it's always welcome to create a GitHub issue to discuss.

Hopefully it would help.
Cheers.